Coming from old school 'non-agile' financial world focused on bottom line I was in a bit of a shock learning about this daily standup ritual.
Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
Do these extra bureaucracy layers, meetings, checkmarks and vague "man-points" estimates actually bring any value.
Agile is at is core just some suggestions for teams to work well together. There are no stand ups or sprints or whatever.
Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked). There is an interview/article by one of the creators of the agile manifesto (Kent Beck maybe?, will try to dig it up and edit the answer if I find -> was Robert C. Martin, see below) where he explains a bit the story and compares it to Agile (and basically says scrum has nothing to do with the original agile manifesto)
On a personal level, I hate scrum. The stand ups, the sprints, the retros or grooming or whatever they have nowadays. It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it. It may work for others, but for me personally, I hate it with a fervour.
Though I agree with the Agile manifesto though, unfortunately it isn't very 'manager' friendly so you usually get scrum instead.
Edit: link to a reference to the article, can't find the original but found this: https://www.aaron-gray.com/a-criticism-of-scrum/#scrum-strai...
I'm sure some super special orgs out there can counteract this with their incredible non-toxic culture and such. Most cannot. Ones that explicitly think they can almost certainly actually cannot.
If it's solely the IC's, I think that's where it can be good. People feel a lot more free to not say anything if they don't have any blockers and don't need to put anything to the team. It's much easier to get in-and-out and have a high-bandwidth discussion.
I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. And we had an open-door policy (not literally/physically of course) if you ever needed to discuss blockers or put things to the team. "Standups" happened naturally, about once or twice as week, where people would accrete into a standup in the middle of our pod discussing something that was so interesting/relevant that it naturally drew us out of our offices.
Maybe that was just the only time where we finally had the team and the process mesh on a natural level, and it doesn't prescribe this as "the way to do it" for anyone else. But damn did it work for us, for at least two years, before the org changed enough that our team didn't really exist as the same team anymore.
One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". That and everything related to it was awful.
I'm old and I worked at Ingres when they decided to write a new release and everyone went off and worked on it for a year. It was right on schedule. Then they got together to release the product and found that each team had developed a component that failed completely to interoperate with any other components. Have you ever heard of Ingres?
The key to their failure was that they never put the pieces together.
So agile is a bunch of techniques to let people work together on exceedingly complex projects. Calling it agile is indeed just marketing. It is basically a messaging bus. The idea is that those Ingres people could have had some meetings to talk about how their components worked and things would have been better. Maybe not great, but better.
And if those people understood that their goal was to give others insight into how they were doing things, that would have been even better.
But think about this - what if from the very first day they just ran the whole project with all the components? Even if all the functionality was stubbed out, at least they would know that it worked together. We do that now, or we should - continuous integration or whatever.
I knew a person who was a great person and great programmer who had worked in the industry for eight years. And not once had the product they worked been used by another person. Think of all that waste.
So yeah, ignore scrum and agile and all that if you have something better. Its not a religion, its just one way of working together. :-)
Agility is just what it says: a philosophy of flexibility and adaptiveness.
Heirarchies, heavy processes, etc are by definition inflexible. They are not agile. You do not do agile. You are agile. You are agile because your company has a culture that is agile and you cannot achieve that unless the company is structured to be flexible.
I think actual agility is really, really a great way to build software efficiently... but unfortunately most programmers will only experience the cargo cult forced upon them by certified scrum masters... and this is just as bad, perhaps worse, than old fashioned waterfall.
More than anything, working in an agile environment is a very pleasant thing to do from a human standpoint. But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us.
If you never seen this, you should read this ASAP: https://agilemanifesto.org/
Because that's all there is to know about Agile. Obviously it takes a bit more time to really grasp how can you translate that to lines of code or building a deployment pipeline or shipping features, but if you understand these couple of lines, you already know enough about agile development.
Sprints conceptually make sense. We have 3 features we want to develop. Lets aim to complete them in the next 2-3 weeks. I like them so long as the goals are extremly well defined and managed. Too many teams though forget the agile aspect of agile development. If there's a change to the priorities, its often poorly communicated or just added to the sprint without removing anything.
Daily Standups, as practiced by most teams, are a waste of time. They become status updates for the Project Manager or Team Leader.
What would be better is for engineers to use the time to review ideas, issues that have cropped up and ask questions about the codebase or specific issues. This is probably what a standup is supposed to be but when its mixed in with the context of status updates, it always takes a back seat.
Pointing is a complete waste of time. I have no idea how long a ticket is going to take until I start working on it. Estimations are usually wrong anyway. If anything, tickets should be pointed once the work is complete to track a teams acutal performance and velocity (output).
Having the team review tickets for the next sprint (sprint planning) is useful for inital discovery (so long as it doesn't involve pointing). One person on your team might know how to solve a bug ticket or know if a feature ticket is deceptively difficult. That discovery process can be extremely valuable.
Overall agile ideas I think do help more than they hurt but not always and not by much.
Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
Again though, I’m not losing any sleep over this it’s just an observation from 9 years of experience as a web developer working for mostly SV tech companies large and small. It won’t be everyone’s experience, and in general the best advice I can give is try to come up with solutions using your own experience and opinions over those people implicitly/explicitly tell you to follow because they are “good”.
Too often though in practice it devolves into a kind of cargo cult and the apologists lean way too hard into the "if it isn't working, you must not have believed in it hard enough" defense which is a bit too easy in my opinion. It short circuits any actual reflection and learning.
Basically, the agile manifesto is great.. the stuff agile coaches try to sell you is hot garbage. Everything else is somewhere in the middle, but Kanban is the closest because it preserves the "we are uncovering" part of the manifesto.
But in all seriousness - scrum as it is practiced today is not beneficial. It's mostly used for "accountability" rather than the "collaborative/communication" mechanism that it was supposed to be. Add into that situations where product/program management questions every little estimation decision (e.g. do you really need those system guarantees? can we leave automated testing out of the MVP to reduce story points).
Agile has been corporatized (if such a word exists) and is no longer "agile".
Scrum agile works when...
- People keep standup updates short and sweet, so standups take 15 minutes or less.
- Your team has a single product owner who speaks to customers and is empowered to make decisions.
- Team members invest time and energy into backlog grooming/refinement, ensuring stories are thorough and have good requirements.
- The team retros regularly to address issues.
- The team communicates often outside of the regular ceremonies, so that meetings stay focused.
Scrum works poorly when...
- Standups turn into 30 minute to 1 hour "status" meetings where everyone brings up every question they have.
- The product owner isn't empowered to make decisions, or your team has multiple product owners who decide by committee.
- Team members are disengaged or not even consulted during backlog refinement, and stories are missing critical requirements that you have to deal with in the middle of the sprint.
- Retros get cut because "there's not enough time".
- Nobody talks outside of the regular ceremonies, so meetings drag on forever.
Scrum agile doesn't work for every organization and every project. Sometimes company culture is too hard to change. Sometimes the work you're doing can't really be done in an agile way. Sometimes the organizational structure makes it hard for a scrum team to work without consulting multiple layers of bureaucracy. (That's my project right now, and it is NOT fun.) When that happens, you have to either relax the rules of scrum (being careful to avoid the pitfalls I mentioned above), or adopt a different process altogether.
If you want to listen to a couple of guys I used to work with who really know what they are talking about, check out this series: https://www.youtube.com/channel/UC758reHaPAeEixmCjWIbsOA/vid...
I really don't get how people come to this conclusion about scrum. The alternative to scrum is the Project manager dictator regime, the literal micromanagers dream, where the pm can at any time jump by your desk and say "drop everything you are doing, and do this thing for me right now", and where the estimates are just whatever the PM decides to communicate, but when you fail to deliver a fully functional product in the 2 months the PM pulled out of thin air, it's somehow your fault.
In Scrum, the PO should be prevented from micromanaging, since he's not telling anyone what to do. There's a product backlog which the PO can prioritize sure, but that's the level of interaction. The team pulls work into the iteration backlog, so nothing should be picked up that the team doesn't agree to do. And each individual team member picks tasks from the iteration backlog, so nothing should be forced upon you. As for the daily stand-ups there should be no management in that meeting, it's a 15 minut maximum meeting between only those who have items in the spring back-log, which most often should not include the PO. If it's turning into a day-by-day status meeting you need your Scrum Master to step in. The board and iteration deliveries should be enough status to go by.
As for sprints: for a few months I have been in a team where there are strictly applied. There is so much time lost: basically the sprint is either too short or too long. After a few "failed" sprints time estimations will become very conservative giving a lot of slack. Personally I am not comfortable with so much slack, it undermines my motivation.
In my experience anyway, as pressure increases sprints are less strictly enforced, for the sake of efficiency. Also approaching delivery the software has become quite complex and bugs tend to be complex has well, hard to estimate precisely. The fact that sprints do not hold under pressure is an indication they are not suitable for SW development.
There is also much time lost in the 2-3 days preparing for the next sprint, because we just cannot spend full days on meetings, for both human and material reasons. Those days are only "half worked".
- Standups don't need to be daily - it's too much. Twice a week is okay (this can be adjusted depending on team/product dynamics).
- They shouldn't consist of everyone telling everyone else what they're working on. This practice is boring and useless to anyone who is present. (If you want to check what I'm working on, log into the issue tracking system and look at the tickets against my name.) Instead, standups should focus on pieces of work that need to be delivered or that need to change status.
A perfect example of this is the misuse of things like story points. It's supposed to be a reference as to how complicated a task is to complete. Ideally, over time, management gets a sense of how many "story points" a team can complete in a sprint. In practice however, development teams basically get brow-beat into treating story points as shorthand for how long they think something will take. So for example, something that involves a bunch of basic drudgery that has no real impact on the system gets scored high. Whereas some minor change deep in the bowels of the system that breaks a cascade of tests and causes massive regressions gets scored low because hey its only 5 lines of code!
Remember the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Scrum: nope
Daily standups: awesome, do them, if it works for you and your team. Don't let anyone fool you into doing something called one that isn't. Actually stand up (if you're able). Actually demand everyone (who's able) does too. The end of the discussion is when someone's uncomfortable. If that cuts the discussion too short, tailor future ones to accommodate them. Repeat until unnecessary.
Real agile (and real things that are actually used in agile) are not micromanageable, they're the antithesis. I highly recommend a read/refresher on the actual Agile Manifesto. All of the things described here that sound nasty are just what agile was challenging, in agile clothing.
Edit: oh how did I miss my favorite target?
Sprints: definitely not for me. They're the Trojan Horse that lets all the fake agile stuff in. I prefer Kanban, but whatever flexible, adaptive, communicative system your team chooses go for it.
I strongly suggest that they accomplish this by using "sprints", because then it means that they only have to manage the communication before and after sprints instead of ongoing. I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
Almost every team ends up doing daily stand ups, and when they don't it is usually because of timezone issues, so they find a substitute. This seems to be something that many engineers fall into as a habit to help keep each other unblocked.
The one thing that is problematic for my approach is predictability. If teams don't have an inherent value of completing sprint goals, then work carries over from sprint to sprint, and stakeholders can't predict when things are going to be delivered.
There are many pitfalls. For example, giving product owner and even manager roles to the lead engineer or architect, daily standups devolving into telling people what ticket number they have in progress as opposed to blockers they are seeing or actually working on, product owners not showing up to backlog grooming sessions leaving engineering to make their own priorities, product managers being the engineering manager and leading retrospectives making everyone biased to say what went well but not things to improve on, agile release trains having teams that don't really interact with each other leaving engineering teams tuned out during system level PI planning and demos. The list goes on.
The current state of an org implementing agile/scrum can easily lead to what David Graeber calls Bull*hit jobs: https://www.youtube.com/watch?v=kikzjTfos0s. The onus is on the organization's leaders to take everyone to the desired state. However, all too often the actual leaders of an organization are the engineers themselves and would much rather get work done than to micromanage.
Agile the stuff people make you do in work is often pretty anti-thetical.
Scrum as a process is basically poison.
Nowadays, because folks don’t like to work with older devs, I’m forced to work alone. Although this limits the scope of what I can do, it has allowed me free rein to formalize a manner of programming that has very good results.
I call it “Evolutionary Development”[0]-[2]. It requires a great deal of experience (not intelligence or education). Thankfully, that’s a resource I have in abundance.
[0] https://littlegreenviper.com/miscellany/evolutionary-design-...
[1] https://littlegreenviper.com/miscellany/forensic-design-docu...
VS
Sprints and daily standups.
---
Daily standups are too often, not enough updates, and it feels more like pressure than utility for the engineers.
Sprints, while helping keep multiple teams working on a single "epic" or "feature" in sync, also feel like an arbitrary slice of time vs. letting people work on things at the pace they are comfortable at. Finish early? Careful taking new work in, it will look bad to bring new things into the sprint and not finish.
Take an extra day on a story due to some complications? That's fine if it's middle of sprint. But rollover into new sprint? Oh gosh, what will that do to our sprint report?
Time estimations, maintaining backlogs of work and prioritizing, and documenting work done are all great. But some of it has too much ritual to it.
If you've never worked in a Kanban environment, I highly suggest you research it and encourage your employer to experiment with it.
I've even seen officially certified scrum masters using it in ways that go completely against the ideas that are behind it.
The main idea of Scrum is, to empower the entire team to decide on their own processes through finding consensus, and to get rid of annoyances that slow things down.
If Scrum itself becomes that annoyance that slows you down - then according to Scrum you absolutely need to get rid of it.
All the different parts of scrum should be considered an all-you-can-eat buffet. You are not supposed to eat all of it - you are supposed to just pick out the things you like the most.
The only core principle is to regularly meet up and discuss how to improve things. That cycle between two such discussions is typically called "sprint" - and that meetup where you discuss improvements is typically called "retrospective". Nothing else about scrum is a requirement. It's just a list of things that worked for some other teams - doesn't mean it will work for you.
Management needs tools to detect (1) slippage, (2) true cost, (3) emerging issues.
Engineers need to not silo, work together, make progress, and share status.
Amazon would do it at 11am, and it would last no more than 10 minutes for a small team. Every two weeks, management and engineers get in a room to holistically determine where things are at, and then they go and report status up.
What I would tell teams that I bootstrap is that the process itself doesn't matter, but the team needs a shared discipline to be effective. Their team has desired outcomes and everyone needs to be accountable for making progress.
Then you check in as a group on a weekly, or maybe twice-weekly basis, with an explicit goal of identifying risks and uncertainties that have arisen during that timeframe.
The goal here is not to micromanage, but to give a sense of progress towards a goal - whether a metric shift, a release, a roadmap commitment, etc. If you don't hit your interval milestones a few intervals in a row, your high-level thinking about timing is wrong, and you need to adapt the project or the timing.
It's meant to help keep the team aligned on what everyone is doing at a higher level, not for any details at all. After the standup, the team can address any requests for help that came up as needed. But that falls outside of the standup.
Agile is meant to help empower teams and improve their velocity, and that requires people to own their own stuff. So the standup should be a purely informative, high-level overview of where the team is so everyone is aligned. If it's anything more, it will become a cumbersome, painful exercise in micro-management and tangential discussions.
Doesn't mean there isn't value to companies that have succeeded with it, or created a value culture around this coordination. But my experience was a bunch of people sitting around talking about what color paper should be used for a particular work item on the sticky board, which I struggle to see the value of.
In my mind scrum has less bureaucracy than that.
Scrum Meetings are best used as a way to come together as a team to work how to make progress today.
For example:
I want to deploy this change to prod today, but one of the tests is failing and I don't know why. Ok lets get a couple of people to mob on the test to figure out whats going on after scrum etc
That's a good scrum meeting.
Bad scrum meeting. Person 1: I did x yesterday. Person 2: I did x yesterday etc Person 3: I tried to get x done yesterday, but I got stuck i'll try again today.
No value whatsoever.
The emphasis should be on problem solving as a team, and focusing the team on pain points to get work across the finish line.
To that end i find "walking the board" far more valuable, than status updates from each memeber.
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
Agile is one of those things that seems like a dream for micromanagers, and if the extent of your company's Agile implementation is saying that you "do Agile" then yeah it's going to be a nightmare. But Agile teams are supposed to be largely self-organized and self-managing. I don't want to No True Scotsman this but if you're doing Agile right there's very little room for some external micromanager to impose their will upon you, but there's certainly room for one to crop up internally.
An old coworker used to say that Agile was created by someone who was sexually attracted to meetings. We don't do a lot of them, or we do them with a subset (on our team of ~11 including the manager and analysts, backlog grooming is 2-3 people for example).
Regardless, several techniques are actually worthwhile: Retrospectives for things that happen regularly (they aren't useful for things that happen very seldom). Daily standup as a sync for developers that collaborate the same task.
Estimation? It's about communication. Standups? Communication. Grooming? It's communication. Retrospectives? Communication.
All the bits are intended to foster communicating different issues that ought to be discussed.
What works for my teams in the past was to just pick a process then regularly ask ourselves if it’s slowing us down or is missing something, and change it slightly when necessary. You may need a few weeks to get used to a working routine that works for everyone, and it’s likely that will evolve over time depending on the people and projects. Better to keep processes to a minimum and make it easy to change it in cases something doesn’t work.
Dailies are the most stupid invention ever. Even if its just 15 minutes, its either blocks your "agilitiy" if its on a time-slot that you prefer not to work, or it steals almost an hour because you get out of the tunnel, wait for the meeting, have to get into working mode again.
Standups are good for small teams all working on the same thing, and only if no managers are present. Unless the manager is writing code too .
Kanban seems ok but i havent used it for any period of time.
The various tools are nice for remembering what needs to be done and making shared checklists.
So why is Scrum so prominent in the software industry today? My guess it that, although bad, Scrum is not bad enough to actually completely destroy the productive of a team. Developers are still able to produce output despite the process. OTOH, mid-level managers are able to use Scrum to produce numbers/metrics to make the upper level happy, get promoted, move onto other companies, and make Scrum spread.
Is my view somewhat accurate? Is there anything we as developers can do to help improve our work environment? In the end, are we powerless against the wrath of the management?
The "Agile Manifesto" is just well known platitudes.
Agile!: The Good, the Hype and the Ugly by Bertrand Meyer is a must read.
Summary: https://medium.com/@knL/i-just-read-agile-the-good-the-hype-...
If you don't care about delivering broken software and having high engineer turnover, scrum is just fine.
As an example, I have never had a PM/Team practice Agile/Scrum in a manner where the total amount of Work-in-Progress is something that gets paid attention to.
In my opinion this is a very serious error.
Yet if you look at the original scriptures, you don't find any ceremonies, just a message, and it's more like a guideline than a rule.
I like the message, but I don't like religious enforcement of the ceremonies. Some work, some don't. It depends on your team.
In those areas, I think that simply following the Scrum ritual is not necessarily harmful, however it is almost surely _not enough_. At least one person needs to have read through the scattered stories, built a mental model of the project's function, and have enough experience to start forming a notion of how things will work given the resources available. Better yet, if everyone has done that and can collaborate on a sketch of the architecture. Without this, all of the points poker is just Ouija board voodoo for the non-tech stake holders because nobody could possibly know how much effort it will be to build that 'Implement a button to do-complicated-reporting-process' down in the backlog.
However, I have witnessed several teams where conversation around architecture and data model simply doesn't happen. On sprint one, everyone gets some stories, and goes off to do their thing. What you get is a minimally-coherent-to-satisfy-the-story data model and massive duplication of effort and code.
That problem should be taken care of with story grooming and the regular, deliberate, refactoring and tech-debt pay down but I don't see that happen very often in practice. Everyone is in too much of a hurry to stop and say 'wait, this code is demonstrably garbage and we're doing it wrong'. They just build around the weird, wrong, or inefficient parts and get their stories finished.
If I think the level of process and granularity is overbearing I say "no thanks" and pull the "Individuals and interactions over process and tools". If there is one thing that I wish I would have learned earlier in my career is that it's really ok to say "no thanks".
Can the team decide they don't need dedicated standups, and stop doing them until they decide they want them again?
If not—if management mandates them, if some single in-charge person (who may or may not also do some programming on the team) would, all on their own, be able to veto that change even if every single other person didn't want them, and even if offered alternatives to suit whatever needs they actually have, or if you'd feel uncomfortable even bringing it up even after you're pretty familiar with everyone there, or if you're not even sure when such a discussion might occur ("pretty much any time" is the best answer, but "during a retro, and only then" is... OK) then very probably the agile you're in is bad.
If that's something that could, plausibly, happen, then there's a decent chance it's the good kind.
One way to get a sense of this if you're new (even during an interview) at a place that actually claims to "do agile" and has done it for any length of time, would be to ask what they've changed about their process since starting. "Nothing", especially if accompanied by seeming baffled by the question, is such a bad sign I'm tempted to name it as sufficient evidence per se for a "run far away, very fast" reaction. Citing deliberate abandonment of or modification to any major agile "ritual", arrived at only after initially trying it the normal way and not just because some manager said to change it, but because the team wanted to, is a very good sign, though just because they haven't done that isn't necessarily bad. The point is: is agile a straight-jacket for the team, or just another tool to use as they like.
There are lots of other bad signs one might see (multiple teams in a standup, standups becoming perform-for-the-manager prove-you-did-work describe-every-little-detail-of-your-"struggles" garbage-micro-management-meetings ruining every single work-day, et c.) but that's an easy one that can be checked for even in the absence of other obvious problems.
In my experience only one company of the six I worked for was doing real Agile. Really short stories, the entire team (inclusing devs) talking to the customer, meetings reduced to a minimum, xp practices all over the place. High value produced, happy customers.
What I noticed about it was that: - every single member of the team believed in it, so no protests - management believed in IT and paid for both agile and xp coaches - hiring was being done right, hr on the first call already clarified what we expected so zero false positives in the hiring phase, new hirings didn't need convincing - slow hiring. The majority of devs hates agile, scrum, pair programming, testing and talking to customers
I left after 5 years to try something new, I still don't find something as good as what I described above.
I then worked for both startups and corp but when they do it, they do it wrong: focused on the process and not on the outcome. People were told "scrum is mandatory because we are doing the digital transformation" or whatever. No measures of the outcome.
Anyway, I firmly believe in Agile, I saw it working in a product company that made billions.
Unfortunately the movement got polluted with consultants that need to sell their service so I personally think you need to get lucky to find a proper place to do it.
Agile at its core is about a few things: committing as a team to work (shared accountability), creating reasonable expectations of what can actually be delivered (as opposed to how much the boss wants to get done), creating a cadence of delivery that is aligned with value to the business, and continuous improvement (through metrics and retros). It’s not perfect, but an agile process run well creates consistency, which over the long run is very important.
Scrum is a way to force communication, create awareness, and adjust prioritization. A lot of people think this is a waste of time, but a high performing team requires excellent communication and this is one way to achieve that. If your team is not getting value out of it, that might mean people are too silo’d.
Having said all this, it’s all about how the team works together. These processes are meant to focus a team on delivering business value. If a team uses another process and performs well, there’s no reason to be dogmatic.
From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities.
From the team/developer's POV, I personally feel like it gives me more freedom (I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog) and a good ratio between work variety (I have the opportunity to work on something different every 2 weeks) and work stability/visibility (once the sprint planning is done, the sprint backlog normally won't change for 2 weeks).
> what are the pros and cons of daily standups
Ensure that everyone in the team is on the same boat. Encourage communication between developers<->developers and developers<->product manager.
I often read on HN that daily standups is micromanagement, but I've never felt it that way (in 10 years of doing agile/scrum in different companies, from the developer's POV as well as from the manager's POV). I guess it can vary from company to company and team to team tho.
That's also the reason they advocate that ideally the team should sit all together. In that ideal work the daily stand-up lasts only 5-10 minutes, it's not meant to be a dreaded status meeting where you talk for 5 minutes then try not to fall sleep for an hour...
Daily Standups are supposed to be Daily Planning Sessions for the Team. But the common implementation has devolved into status update meetings.
So the con is that, more likely than not, it will be a status update meeting, in which case, a waste of most people's time.
If it's a Daily Planning Session, there are no cons, only pros.
The pro is team alignment, with each other and with project objectives and goals, with only a maximum of 24 hours for possible misalignment.
Misalignment is ALWAYS the problem. Daily Planning Sessions help mitigate that ineveitability.
I.e. a popular set of productivity tools with a cottage industry of people trying to teach it behind it.
If you look at it as a set of tools, you can make something really tailor-made for your team and on occasion it lead to creating a truly bespoe process that fits our team needs and doesn't have anything to do with scrum anymore :-)
With things like standups, backlog refinements, storypoint estimation, based on my experience this works for team of 3 to 10 people, with a clear responsibility that work together on a project for at least 6 sprints (usually 2 weeks/sprint), where new work can wait for new sprint to start.
It helped us focus, storypoints started to work for estimating stuff after ~3 sprints, our managers got used to "no, we won't start working on it right away, put it in the backlog, you will join for prioritization anyway".
You say Agile disrupts your "flow", makes you deliver buggy code and just work to close tickets like a drone?
Good! Who said code needs to be perfect and bug-free? remember Lean? Just get it out there! we can always fix things later.
From a business perspective - we are spending money to develop functionality, not our peoples skills. Tickets and tasks should result in adding value to the business, not to our codebase.
This is a cruel and unsustainable way of thinking, which will have your best developers leaving the company very quickly. But if you're an enterprise corp - you see them as interchangable "resources" anyway, and Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This is also a way of looking at things...
Holding all else constant I hope to have a job where I am not on the spot for making some unknown amount of tangible progress every 24 hrs. Deep work cannot take place in short, consistent staccato steps. Sometimes big moves forward happen in a day. More often it’s a day better spent thinking hard, rather than thrashing around for quick answers.
Moreover, if I have to ask for extra help to make progress quickly and consistently, I miss out on the learning that trying things myself would provide.
In addition to being very unfulfilling, this means that I do not grow to properly understand the codebase in a timely fashion. This means I will under achieve over the long haul. All the better to judge me inferior I suppose. It can be quite toxic.
Scrum is incompatible with Agile principles.
It has backfired, because most organizations cherrypick what they want about Agile, and discard what doesn't adjust to the "way we do things here".
In case this resonates with someone, I wrote more about it here: https://alvaroduran.com/essays/against-agile/
However, I spent some time working with contractors at Pivotal and I met an EM at one employer, and these people seem to take this stuff super seriously and get good results. The difference is that they do not just have standups and backlog grooming and retrospective. They do EXTREME PROGRAMMING. I am not sure if this is suitable for all kinds of work, but it was highly productive in my experience.
In that case though, the answer to your question is still "no," because there is no extra bureaucracy and because the points exist to serve the team rather than management.
Being able to throw all of that in the bin and just say "we're Agile, so it'll be ready when we all agree it's ready, and we'll direct effort where we think it's most needed as we go" is awesome.
I've never worked with Scrum, but I have solid negative opinions on it (so hopefully I never have to). One of the core parts of the Agile Manifesto is "people before process" and Scrum is all process, so I'm always confused as to how the two became synonymous.
* Sprints - Instill a sense of urgency - Reduce scope to a manageable set - Allow for short-term planning and reflection (and short term is the only term that works) - Align the team
* Daily Standups - Provide a relatively cheap and high-bandwidth way to disseminate information. - Keep the team bonded and allow for early course corrections.
But the books is full of gems, so my two sentence overview doesn't do it justice. Read it here https://basecamp.com/shapeup
With that said, I don't expect any manager to allow us to try out. People love that they can hear people every day that they are all very busy.
My current Scrum experience is from a large retail company. Our mobile app team of ~8 devs tries to keep up with the web team of ~50 devs (or even more, I just started and we work remote, I have no clue about the exact numbers).
The schedule, roadmap is mapped out for at least the next year.
Then, the Scrum doesn't make any sense. We can't decide what's important for the user. We can't work on bugs (that makes the lives of our users miserable) because we work on big feature launch X, and if we don't finish, it will jeopardize big migration Y in 2 months, and then it'll make big relaunch in Country Z impossible in 4 months.
It's waterfall with two-week crunch times and daily standups. And our ratings in the app store are constantly declining. But hey, at least we are on time, no matter how terrible our app is, in Jira it says it's shipped so don't whine about software and product quality.
During my whole career (about 5-ish years), I didn't find a place where a standup every day made sense. I think two or three sync-sessions per week would be perfect. Daily standups just made anxious, nobody listens to the others, you either say too little or too much, and the original promise of standups just didn't match my every day experience: we never found blockers we wouldn't have found otherwise, etc... In my opinion, pair/group programming (2-3 ppl) is thousand times better.
Whether people say it is good or bad, it is useful to understand the context, scale and criticalilty where they came to that conclusion. Otherwise it is very difficult to compare answers.
I also don't like points generally. To some degree you need some kind of estimate, but estimations are notoriously inaccurate, so just embrace that and stick a "days/weeks/months" label on something and call it a day (though if it is weeks or months, it should probably be broken down, but I do that on-the-fly as I arrive at those bigger tasks and develop an understanding of what's involved).
I actually do find standups useful in my experience, because in my team we have a couple individual contributors working largely independently on independent components of an overall software suite. Some of them are new and so might try reinventing wheels we've already solved in other compartments. By having a dedicated time for people to just talk about what they're doing, more senior developers can catch when wheel-invention is happening and steer the more junior developers towards existing solutions.
But above all, don't cargo-cult any practice. Find what works for a specific team and run with it, because different teams have different needs. That's the real essence of Agile.
And then I've seen it fall apart, in the exact same place, because upper management wasn't getting progress reports in terms they understood.
It can work, and work well. But it's far less automatic than people think, and far more likely to turn into cargo cult agile.
So instead of, on hand, having constant daily storm of thing, or, on the other hand, having tasks that take forever and never end, you have time-boxed 2 weeks sprints that you plan beforehand and do them. It's not overly planned for the next year, it's also not no planning, it's "just right". Management is happy that they see what is going on, developers are happy that they are not micromanaged.
Daily meetup is just to check up how things are going. It's good, but it needs to be really checked by someone to not exceed some time and not be yet-another 1 hour meeting.
All the other things can be safely ignored; all those managers and owners and masters, they would exist with or without scrum and they effectively don't matter all that much.
What I do hate is "story points" and "velocity", because they at the same time don't mean anything and do mean something. In my head I convert them to "mandays". I don't know why people don't call them "mandays". "But they are not mandays" you say... well they mostly are, let's call them that.
I never had experience with all the other weird rituals like the cards.
1. I get to see the progress of the project as a whole on a daily basis. Without the stand ups, I probably would have no idea how and what we are doing as a team and I'll just be doing my own thing.
2. There were times I mentioned an issue I ran into and others chipped in with helpful ideas (sometimes even the solution) saving me time. If it weren't for the stand up, I would have just solved it on my own anyway but could have taken more time. In a way, this opens up a helpline.
3. If you are a team lead, this can help make things more predictable. There's an understanding what everyone is expected to do in a regular meeting than scheduling meetings when you think is needed but others may not have the same motivation for a meeting and can end up same few people talking every time.
I hate meetings in general, but I hate surprises even more. So, seeing meetings pop up suddenly on my calendar is something I really dislike. Agile and the stand ups at least make things predictable like short 20 minute meetings every day. After I get through that, I know I'm not gonna be bothered again for the day :)
Agile works best in environments where the scope or execution methodology can not be discerned up-front or where it is crucial you need assurance that expectations are aligned. Your risk profile is much higher due to the number of unknowns, so a lot of time is spent doing work "around" the design and delivery of said thing to mitigate all that risk. As such, it works well for mostly corporeal endeavors such as building new software, or things that . This helps operationalize a feedback loop of try, test, re-align, try, test... etc. across stakeholder groups to help make small rapid course corrections until you get to where you need to go or abandon at an optimum time without marching like lemmings to a cliff.
It also works well in technical environments where there is a lot of collaboration and interfacing between different specialized groups. Forcing everyone to come together and be accountable for their dependencies to each other reduces those instances where blockers, compounding delays and finger pointing send things off the rails.
Estimating, assigning, controlling and monitoring, what you would typically term "earned value", in a project management sense is extremely difficult for these types of things. If the scale of work is large things naturally land on amounts that aggregate up to something useful
The two things I often see in agile projects/organizations that are often done poorly and lead to failure are:
- Maintaining a proper understanding and separation of the delivery risk (risk associated with building, creating) and the delivered risk (the risk you've baked into the "thing" by aspects of its design)
- Not allowing for or tracking risk mitigation, or how residual risk is trending
- Thinking because every project is unique that they are unique and therefore need a unique way of managing the project (i.e. re-inventing basic project management methods)
- Thinking your business is unique (it's not, less than 10% at most) and that therefore everything you do, including how you execute projects is unique (you don't).
Agile is defined here: http://agilemanifesto.org/
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
Uncle Bob talks about it in depth in one of his lectures here: https://youtu.be/SVRiktFlWxI https://youtu.be/qnq9syXUuFE
And in his book Clean Agile: Back to basics.
Agile is for quick feedback on made progress, to compare it to expected progress and to be able to report your progress and forecast to business people to let them know how far behind the schedule you are as quickly as possible.
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
Uncle Bob talks about it in depth in one of his lectures here:
https://youtu.be/SVRiktFlWxI?t=1807
https://youtu.be/qnq9syXUuFE?t=3400
And in his book Clean Agile: Back to basics.
Sprints:
- pros
Helps to avoid continuous changing direction at request of stakeholders. 2 week sprint feel really good as planning horizon: not too long, not too short. Teams do not commit to anything beyond that timeline. Any roadmap commitments are based on stats and product owner responsibility. Team is not accountable for any missed deadlines.
- Cons:
It can feel like wash-rinse-repeat sometimes. Can be a killer for flow and feel inflexible when you are nearly there (getting it done) and the sprint review interrupts the flow. If the balance is bad you should probably look at kanban.
Daily’s:
- Pros
Excellent way to find out if team members need help or some syncing is needed. If done well team will “feel” if your getting closer to getting everything done. With work from home good to see everyone on the team at least once a day.
-Cons:
Hard to get right. Should be about inspection by the team to help adapt the plan and get to your goal, but this is often forgotten. Might become a way to “control” the team and put pressure on people and check for performance of individuals.
As for micromanagement: this is not exclusively found in agile / scrum. A micromanager will find a way to abuse any method to “control” their world. If you let go, set a clear purpose and direction, start helping team members to get more autonomous you will find that performance goes beyond what micromanagement can achieve.
Scrum (as defined in the scrum guide) can work, when it doesn’t: adapt and try again.
So. If you're not doing scrum you are not leveraging it's potential and even more important, its rules.
The rules of a daily is non-disputable. It has a formula. If you're not following the formula, it's not scrum.
A daily is not about progress. It's about communication. You communicate what you did since the last daily, and what you expect to do before the next.
But you're not being measured on what you communicated. You are merely sharing what you' re doing.
If there is discussion in a daily, it's not a daily. If you're not using a board for the baseline for communicating, you're fucked.
The role of a scrum master is to take note of what is going on and help out if she hears anything that sounds off. A good scrum master is a bit like a dictator. Focused, on top of things, helpful and listens to what is going on and does not bend to outsiders.
Good scrum masters are hard to come by. That's most often imo, why scrum had a bad rep in some places.
Also remember, agile is something that must happen on a top level, otherwise it will not work very well.
It also sounds like there is not very much trust between team members. You immediately go to 'signalling progress vs. actually making progress'.... The scrum ceremonies are actually meant to support an environment where developers trust each other and one developer helps another when s/he could use it.
Editing to add: learning is an important part of being a programmer. Experimenting, reading the manual, trying it out, these are all things that get managed out, when you have to beg for "spike" time to do them, and somebody else doesn't see the importance.
The upsides are that it does make it somewhat easier to pivot or to shelve-and-resume when you know which of the bitty pieces are still to do, and it makes long term estimates slightly less arbitrary.
Agile gives you principles as to how to envision developing software. Scrum is just one implementation that tries to follow these principles.
I'm not a fan of Scrum, although I can understand why some of its components could be attractive. Velocity for example is interesting, as it's an attempt to empirically measure how "fast" a team can develop, and base estimations on that instead of just throwing a bunch of hours/days as an estimate when in fact it's hard to do that. I still think it doesn't work well to solve this, but to be fair I don't think there's a single method that solves it.
In the end, I think Agile is beneficial (in my experience!) but more importantly that you need to use and tailor a software development methods to your own needs and context, and stop blindly following existing models but instead see them just as what they are: tools.
As another example since you mentioned it: daily standups can be good, or terrible, it depends what you make of these. I've worked in a company where it was basically a "scheduled waste of time", but I moved to a place where we mixed it with basically a "hey good morning" type of coffee break and it worked rather well in a casual way, chatting up what was coming and that's it. And we keep in mind that if some kind of "ritual" becomes useless, then we skip it altogether as soon as we agree there's no value in it.
That last part feels important to me because that's ultimately where a key aspect lie: when you say it's a "micromanagers' dream", I think it just shows that the software development method can always be twisted and hijacked by some people given enough power/representation/influence.
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
There are about a million discussions about how broken Agile is, most of which discuss some abomination of a process with very superficial similarities to Agile. It's not like having a standup is some sort of magically good thing on its own if people just use it to do things the way they've always done them.
Cue the inevitable "If everybody is doing Agile wrong, maybe there's something wrong with Agile?" response, to which I would simply say that I've seen Agile work in at least two completely different workplaces, and I've seen how terrible non-Agile processes are in at least another two.
Agile has a number of assumptions regarding organizational culture and the people involved on the project. Those assumptions are usually not discussed very often, which is bad, since I believe they are typically related to those many cases of failed Agile implementations that end up getting different explanations depending on how one likes/dislikes Agile.
To summarize what I'd like to answer about your question:
Pros:
- They are great tools to break larger projects into smaller chunks and to keep track of their progresses. Experience shows that it's easier to reach success on smaller projects, and sprints and daily meetings are ways of emulate such sort of project even when working on larger ones.
- There's an opportunity of catching and fixing schedule slippages, requirements misunderstandings and other sorts of deviations before they get too expensive to fix.
Cons:
- You need a bigger deal of maturity and commitment of people involved. As IT professionals, we usually complain about users being unprepared for working on Agile projects, but we have to admit that many professionals show a significant decrease in performance when they are not under a certain level of healthy pressure.
- When you favor people over processes and communication over documentation, a higher level of mutual trust is required. You can't find that everywhere, for a number of reasons. Some say that such organizations are not prepared to work under Agile rules. Some are more pragmatic and adapt. I stick with the latter. Agile talks a great deal about embracing change on requirements, and I don't see what is the point of being a purist and refusing to adapt the method to deal with risks.
https://on-systems.tech/109-toward-predictable-engineering-v...
Far better in my experience to spend time analysing the requirements as a whole, to distil the essence of what's being developed, and design a set of components that express that essential nature in a flexible way, such that the features arise out of the combination of those components rather than being developed in isolation and then mashed together as the project progresses. Accept as a given that intial requirements are just a best guess, and design accordingly - to cram piles of poorly-thought-through code through reams of unit tests is to fight this reality, not to embrace it (note that this is not to rag on unit testing itself, which, like any good tool, is extremely useful when deployed appropriately).
Doing this kind of analysis up front and then developing the components using scrum - that would probably be OK, but I've yet to see or hear of anyone doing that.
As for the process side of scrum: stand-ups are fine if they are kept very short and simply used to express and work through problems, but this appears to require active policing to prevent people rambling, and the retrospectives again are potentially useful, but in my experience turn into long awkward sessions of scratching around to find items for the 'things that went well/went wrong/would change' lists - and more often than not 'things that went well' could be summed up as "we all did our jobs". Celebrate genuinely awesome results, sure, but as a software developer, I don't need or want a pat on the back just for developing software successfully. Overall I would say that the principles of scrum sound nice but when they meet real people the results are somewhere between mediocre and painful.
The pro of having a sprint is that the team knows what they can do in advance. I don't need to ask my boss for a new task, I just pick the topmost of the board that's not been worked on. The con is sometimes added pressure to finish a sprint (beyond normal pressure and without real-world cause) and a lot of time wasted in team wide meetings to plan a new sprint.
'refinement' meetings as far as I understand are unfortunately usually a waste of time.
Estimations in terms of 'effort' points are a recipe for failure because ultimately they will be converted into man-hour units yet were not supposed to think of them as time but 'complexity'. As a result velocity and burn down tools are just a cause for strife. I'd recommend using a normal time unit instead. Skip the conversion.
The other way these things can possibly be made useful is if the most important metric is not velocity but reliability (which most teams don't use but is used in at least one team in my org).
Retrospectives have the potential to be a cause of strife for obvious reasons. Usually they are pointless because people understand it's a powder keg so you never learn anything.
Personally I don't like agile/scrum but if I'd have to do it myself I would keep at least some elements, like the board you can take tasks from. Standups I would like to see alternatives for. Estimations I would try to do myself or maybe have a tech lead do. I wouldn't even bother communicating it with the rest. Ultimately I never learned anything besides agile scrum so I'd have to adopt at least parts of it no matter that I dislike it.
In that sense scrum is like "training wheels for self organizing teams". Once you understand the benefits, a small team should be capable of modifying the system.
If we look at productized processes Kanban is much better at getting the essential framework in place.
Scrum is not the worst process that could be applied to software production for large orgs. Worse examples include for example a no-process, hardware companies shoehorning software development into hardware development framework and so on.
IMO as a junior dev over a decade ago it was nice to have scrum when I started at a company since that framework made it very explicit what the rules of the process were. A no-process would have been much worse and stressful.
But high performing teams tend to realize there is no one shoe fits all solutions to complex processes and then evolve their own system.
Having said that, I've seen a lot of agile projects fail, because people are too busy worrying about being "agile", while forgetting to apply common sense.
I did my first scrum training with Ken Schwaber. Ten years later I did it again with a "Scrum Consultant". Same "processes", but utterly different reasons, utterly different outcomes.
And there's no hope for it. Managers can't be convinced by me that Ken Schwaber didn't mean whatever bullshit their high-priced consultant is saying. Even without the consultant, there are far too many ambiguous things, that Ken gets into specifically, that don't come across when discussing Scrum. Scrum will result in the manager doing none of their responsibilities (e.g. proper planning), while micromanaging the engineers.
If I ever start another company, we will do Scrum. But otherwise, I won't go near it.
If you consider things in the Agile Manifesto and the spirit of being agile, the pros are things like you don't waste time building stuff nobody uses. Why gather requirements, design, develop, test, deploy of features that have minimal or no usage. I've seen many cases that by the time a feature gets out there, its not needed/wanted any more. There are charts and stuff on this regarding Lean Software Development. Another pro is barriers are identified quickly and can be problem-solved quickly. Figure out your unknowns really early and you can adjust what you're building.
Over the last year with everything going on there were days where at standup people said "got distracted" and that is perfectly fine. I took that to mean they didn't get anything done during the last day. There were some major life distractions this past year. Those meetings aren't for management to keep tallies on people for some fictitious scoreboard, they are there for the team to identify barriers, ask questions, etc. so the work can get done. Agile comes from lean principles from manufacturing, its about eliminating wasteful steps in a process.
Some cons would be with the wrong culture you get micro-managers, people measuring stuff that doesn't matter (ticket size, velocity, whatever) and possibly people gaming whatever nonsense you are measuring. If there is bad culture the project management process being used doesn't matter really, its not going to be pleasant working in that.
If there is high risk in what you are delivering, like if you're building software for controlling a nuclear power plant, ICU medical devices, etc. you may need a lot tighter controls around the project process because software bugs can result in really bad things. Maybe a waterfall process works better in those situations, otherwise use agile that fits the people and organization.
Anyone familiar with Japanese business/engineering process knows that the principal engineering project management fuel is meetings. Highly organized and structured meetings. Our headquarters building in Shinagawa had two entire floors, dedicated to conference rooms, and every floor had at least 4 conference rooms, along with "ad hoc" conference rooms, made up of file cabinets, set up like a grade-schooler's home "fort."
We had to book conference rooms six months in advance, for a half-hour meeting. Once, we were ten minutes late for a meeting, and the booking system automatically knocked us out, and assigned our room to another team. We went out to the coffee shop, but couldn't "talk shop" outside the headquarters building.
Yeah...they take meetings seriously over there.
So my team (based in the US, but run from Japan) hired a really sharp guy to be our process/infrastructure person. He was loved and valued throughout his six-year tenure, and we cried for years, after he moved on to greener pastures (this story might illustrate the appeal of said "greener pastures"). He was a fairly new Agile proponent, and proposed a daily standup.
So, anyway, the spirit of a daily standup, is to be informal and fast. Start of day, 15 minutes, no chairs, lightning talks, very brief Q&A, What I did, What I Want to Do, the Challenges I Anticipate, etc.
So, our Japanese liaison member (the person responsible for learning our process and representing Tokyo's interests to us) takes a liking to these, because...meeting GOOD. You get the picture.
So our "standups" ended up becoming hour-long daily pre-lunchtime events, with a booked conference room, seats, a fixed agenda, and a daily report to Tokyo.
Be careful what you wish for.
The place I work at is doing it wrong in my opinion: sprint points are directly mapped to time (instead of complexity), meaning that each day = 2 points per developer. Stand ups are really just status updates to our product manager - developers don't actually chat to each other about issues, we just report to the pm. If the pm is in another meeting, then standup doesn't occur at all.
The worst thing about it: There is no end in sight. There is no natural endpoint. It's just ticket after ticket after ticket, with the almighty burn down chart looking down on us. It just never ends. In a way we are assembly line workers. We cannot take slightly longer than what the ticket says, then you are forced to explain where you are stuck, even if you aren't stuck, so people thumb suck reasons.
(With something like carpentry, you build something, apply finishes, enjoy the product, AND IT IS DONE. With software development + scrum = infinite treadmill. You get deprived of ever getting a sense of accomplishment.)
During sprint planning we also assign the ticket upfront to specific people, so we have hectic issues with knowledge silo's.
On the sprint point side, we basically either have tickets that are 3, 5 or 8 and nobody dare picks another number. Using their system of 2 points = 1 developer day, some tickets should be 20 points, simply because it will take the person at least the whole 2 weeks to do. Some tasks are inherently complex or tedious and will take longer, but at this company we basically have to rush everything. Nobody ever has downtime and time to think.
I'm kind of over the company and over scrum. Looking back after 10 years, the only place where scrum did work for me was at one company (that sadly closed down (infighting between directors)) where we didn't take it serious at all - it was all for fun, no drama/seriousness, no care about mapping points to time, retro's was super funny (and not a moan fest) - basically nobody took it seriously and our productivity was crazy good.
Another place I briefly worked used old school Gantt charts which worked surprisingly well even though I didn't like it in the beginning (it was a more waterfall-like approach, loads of planning upfront). We would spend a WEEK planning and then code for like a month and release basically near perfect code to production. It did feel a bit boring in a way because there was very little wiggle room - everyone just followed the plan.
Kanban makes so much more sense when that kind of garbage is in your work environment.
There are a few points that are important to it working well though:
* Team size should be small, but not pathologically so. 3-8 is about the range it is ideal.
* Strong ownership and trust between engineer and product owners, both way.
* Engineers should have broad, or at least T-shaped competencies, not narrow, exclusive focuses
* Meetings should feel useful to all participants, at all times. Specifically, standups should be useful to the POs because they get a rough idea of how things are going across the team, but it is also useful to the engineers to ensure that engineers are actually working together, not simply siloing themselves.
* Engineers should be competent, in general. They don't need to all be 10x engineers, but a team comprised mostly of leaderless junior engineers will fail, even more so with Scrum/Agile
It's a good way to set expectations for what will be/is to be delivered in a Sprint, and limits going off-piste in too many directions while not delivering functionality (which is a problem for creative/broad-skillset developers at times).
It also limits the impact/waste in case the requirements change - you only worked two weeks in the wrong direction. (and they say changing requirements is the biggest problem in software projects since ever)
However, I find that it often reduces developers to mindless drones, just trying to satisfy acceptance criteria without thinking about the big picture. (You know you're there when Refinement meetings are very quiet and the Architect does most of the talking).
As for estimation/scoring - I find that estimating "complexity" is nonsense. Treating points as "days" is more realistic and leads to better time management from everyone.
On standups: first, I rarely speak in standup; if some other manager uses it to micromanage, well, that's on them, not on the general concept of daily checkins. Second, it's very difficult to "signal progress vs. actually making it" with your teammates. That's part of the point: intra-team accountability. If you're making no progress, you might fool me with generic excuses and you can certainly fool a business analyst or a project manager, but you can't fool another programmer who works on the same code and sits next to you.
On agile having a lot of bureaucracy layers: compared to what? The agile "bureaucracy" my teams endure is: standup, refinement, and retro. That's less than two hours per week. What methodology involves less bureaucracy than that, other than anarchy?
On points: OK I will kind of give you this one, but only because they don't bring value to you. Story points aren't for you, the dev, they're for PM and execs. What do execs want, in terms of estimates? They want to know exactly when a feature is going to ship, to the day, even if it's years away. What do devs want, in terms of estimates? To not give one, ever, for anything. Story points are the compromise. And pointing a story takes maybe 30 seconds, so it's hard to understand how anyone can see it as onerous.
So in summary, I think agile is very good when done right, and in places where it seems bad it is usually because one of the basic ingredients (a team empowered to change their own process) is missing. That, to me, is the core of agile: a team that iterates on their own process. If your team is not willing to or allowed to do that, IMHO they're not actually agile. And if they are, well, take your objections, bring them up in retro, and propose something better.
In my mind, the benefit of agile is that it encourages a movement towards the double-loop learning model (pg 19), which is a struggle for many people and most organizations, from a single-loop learning model (pg 16) (assuming there is even a learning loop present at all).
The single-loop learning model:
Mental Models of Real World
|
v
Strategy, Structure, Decisions Rules
|
v
Decisions <------------+
| |
v |
Real World |
| |
v |
Information Feedback --+
The double-loop learning model (another ASCII art attempt) closes the loop and brings the feedback back to the mental models (using abbreviations to shrink it a bit):
MM ------> SSDR
^| |
|v v
IF------->Decisions
^ |
| |
+--- RW <---+
Seems like your company is doing it wrong;) Agile is supposed to 1. remove bureaucracy, not add some; 2. adapt to the situation. Before Agile, you would read specs and implement them, and those specs had been carefully written by a team of analysts (8 people for a year). Any change to specs had to circle around the analysts and customers. Agile should first be an improvement on top of that.
But if Agile is still getting in your way, seek to remove that too, and your managers will be happy. Agile should be about adapting. Anything that does not bring features is unnecessary.
Last note for humor: “The wrong way to do Agile” depicts how things actually happened in Waterfall: https://youtu.be/l1yWusiaLCM
1. Better visibility of progress and blocking issues - this is a big plus to senior mgmt and if you're technical it will help you alot that they understand you're making progress rather than being a blackbox that they hope delivers something in 6 months time
2. More adaptable to change - every project changes, the lnger it runs the less suitable it is at the end. Agile/Scrum theoretically allows you to change course better (not that you couldn't do it under waterfall..)
You do make a good point that it can be a dream for micro managers if you're unlucky enough to work for one, there are many potential faults but it depends on who's in the team frankly. The standups can become mundane and useless if people can't be honest about blockers or where they need help as well.
SAFe for larger orgs or Kanban for smaller teams are excellent approaches to agile.
The book 2nd Generation Lean Product Development really gets into the weeds on what works and why.
The game industry is a famous example where scrum just does not work. There are to many pipelines and to many disciplines, and everything depends on shipping.
So in the game / VFX industry there is most of the time a strict waterfall structure that does not help you to do scrum. If the hours a team is spening on a sprint is not the same every time then you are just using postid notes to track the progress. (crunch hours are unfortunately very common in the game industry)
So in general I would say, Scrum/Agile is definitely beneficial if you are shipping multiple versions of a product. But if its all about shipping 1 final product or if the time team members are going to work on it is not specified then you are just using it to track you progress and it is therefor not any better then good communication.
from Pragmatic Dave Thomas: Agile is Dead https://www.youtube.com/watch?v=a-BOSpxYJ9M
Cons: everything else :-)
I enjoy the non-scrum world, but every time I try it, I realize how bad it actually is for everyone involved, especially if there are timelines. But also I think unless you're sufficiently experienced, Scrum is micromanagement hell indeed.
Also our agile approaches mostly work out well, but our whole organization is structured in a way that facilitates this.
We have only 2 levels of hierarchy and crossfunctional groups for arbitrary topics like "wage transparency", "consulting" or "technology". Anyone interested can take part in those and they get some budget too.
Every few weeks there are townhalls where economic development is reported by the executives to the rest of the company and anyone can ask questions. Since covid we do this via google meet with great success.
All in all agile approaches only truly work if acceptance from the higher ups is high. If agile is just used to get tighter deadlines out of devs it is actively harmful.
You can't streamline software development. I don't know why people keep trying.
Daily meetings are not to micromanage and show off that you've done so much work yesterday, but to identify issues that need to be resolved and a good place to ask the team for help if you're stuck.
Unfortunately, agile nowadays is mostly scrum, following some non sensical plan taught by some agile coach and too much management, whereas agile was invented solely by and for developers (not managers).
If by "micromanagers" you mean, "just managers who like to understand how time is being spent", then yes that is what Scrum/KANBAN are for, among other things.
Story time...
I remember working at a startup in the UK around 2013/2014. We had guy working for us who did the UI for the portal our customers used to interact with our service. We had another developer doing the back end in Ruby on Rails.
At this point in time we didn't do Scrum so as a result we didn't do daily stand ups. We also didn't do any form of TDD, BDD or any testing at the code/module/lib level at all.
Fast forward a few months and another programmer joined the team. Really great programmer and big on testing and Scrum. He convinced the CTO to try Scrum and go with daily stand-ups, planning meetings and retrospectives. That was all he was asking. The CTO agreed.
The UI was fired a week later. Turns out he had spent two weeks allowing the side menu slide in and out from the left of the web page. He did this from scratch.
The new guy then convinced the CTO that TDD was important for at least the critical paths through our application. He wasn't asking for 100% code coverage, nor would he (because he's smarter than that.) The CTO agreed.
The back end guy upped and left two months later. Turns out he didn't like doing testing of any kind, so instead of writing useful, meaningful tests, he wrote tests that simply returned "true".
The lesson from this is: Scrum can, like systems, highlight problems inside of an organisation. By implementing Scrum were got a daily snapshot of what everyone was doing, keeping people accountable for their actions, and knocking down blockers sooner rather than later. There is no "micromanagement" here.
These simple systems, like TDD, Scrum, OKRs, and so on, are excellent when used correctly.
Like others said above, Scrum did reduced the time we between when we finish a feature and when it hits production. I like the idea of quick feedback cycle and fast iteration.
But most companies abuse scrum and see sprints as a way to squeeze more out of dev teams. I've been working in a scrum team (leading the tech team as a tech lead, not product owner) for 3 years and I'm burned out now. Trying to get to a different place soon enough.
It is good for the product/managers, but for dev teams it can be bad if not done well.
However scrum can really suck if executed poorly, especially the daily syncs. One of the keys I think is taking things offline and not ratholing, enforcing the time limit (15min), and if there's any manager or PM present not doing engineering work they cannot speak unless spoken to, or perhaps once at the end with any short updates/concerns w.r.t. backlog.
Communication is important (vitally so), just the format is entirely wrong imho.
In most circumstances, one or two updates a week would be fine, preferably followed by the rest of update meetings so more contiguous hours of problem solving can happen.
* Frequent feedback from stakeholders and customers
* Retrospectives
* Standups
These can be annoying but they help make sure that the right thing is developed.
Things I don't like:
* Things get rushed to get them done before the sprint ends (even if there is no deadline pressure)
* On the other hand, everything takes at least two weeks to get done
I feel that this turns the output of a very high-performing developer into that of a mediocre developer. I'm not a 10x developer, so I can cope. ;)
Things I don't like but don't blame on Scrum:
* Jira
* Storypoints
* Estimating: All estimates beyond the current sprint are completely unreliable. Still, people use storypoints to derive release dates and worse, measure the productivity of employees using them.
FWIW, until I learn of better processes, I prefer Scrum without "buts" and with continuous deployment.
In the end it depends on the people, and the biggest thing that can make or break this is the product owner. We had someone as a product owner who had absolutely no political play in the game, he was a designer that stepped in and understood the product. All he did was explain some quirks and come in to help if there are questions or things that are not clear. On the other hand, when the product owner tires to be a manager of the team and the processes, it all goes extremely wrong.
The idea that we could have a call at a fixed time each day to figure out and reorient active development priorities is a manager's fantasy.
Some developers need a whole week to get momentum on very difficult tasks. Breaking their time up into discrete 24 hour chunks where they have to constantly report ambiguous progress can create incredible amounts of unnecessary stress over time.
We are now operating 100% async. I worked with our implementation group to ensure we have a buffer of priority issues so that developers always have a way to grab the next task, even if it's 3am on Saturday. Some people get inspired at weird times and that's totally fine.
`Dr. Andrew's has certainly given his opinion about what we should do next with the patient, but what does Fred think? Fred says masks are pointless. Dr. Andrew, we're all equals here, you shouldn't let your emotions take over. We'd like you to perform this surgery without a mask...`
Luckily, it's just a software management technique, and generally speaking there are enough adults in the room that it moves forward regardless...
Beyond that, it's just a way of doing things, much like an OS. It doesn't matter if you're running W10, MacOS, or some flavor of Linux. If it's the right tool for the job, then it's the right tool for the job. But if it's not, then why is it in use?
Agile/xp started at Chrysler as a way to push back on management on give engineers a chance to pace/structure/set expectations for their work
Modern agile is just a management framework used as an excuse to micro manage the shit out of your work force.
When I first started, we operated on textbook Waterfall standards - I'd be handed an issue from my manager, I'd spend an unspecified amount of time trying to fix it or implement it, and repeat. I had no context about what my other colleagues were doing, or about the greater scope of the project. We had several projects going on at once, which frequently missed deadlines or changed scope halfway through. I might spend a day on an issue, or two weeks - there was no assessment of how complex an issue was. Due to the age of the codebase, various parts of it had no unit tests or documentation.
Some of my other colleagues proposed using Scrum to organise a new project they were working on. Issues were organised, broken down as small as possible, and progress was delivered in Sprints. They estimated their issues, estimated a delivery date for each phase, and met it. They also implemented unit tests and completed documentation for the code.
Over time this method was expanded out to all new projects, with my colleagues organised into teams who focused on one project at a time (while handling maintenance of the older system).
I've found that pairing Scrum with other modern development techniques like unit testing and MVC architecture has made the projects much more maintainable and has given the teams more investment in driving the projects.
We use three parts of Scrum - standups, weekly sizings, reviews. While retrospectives were important early on, mostly everyone is happy with the level of Scrum we practice. A key thing is to not let these meetings overrun - that seems to be everyone's main complaint about Scrum is not letting it distract from actual work, but using the time to better plan it out. My managers can see the progress of a project in rea-time as well, between reviews and looking at the team burn-down mid-Sprint. We can better track issues that people are struggling with on a day-to-day basis.
I've now found it a lot easier to deliver projects on time, and to better justify why delays occur because of the increased amount of planning. My team members are now better invested in the project and morale is much higher. I see Scrum as enabling picking up other good practices as well, but it's not worth doing if you're not also pairing it with these other techniques, or it's just a way for management to hold lots of meetings. It really requires a team-based focus, which is why I think a lot of lone wolf programmers bounce off it.
The problem is that research into software engineering sucks. The silver lining is that some people have done small scale studies on this subject.
The studies I've read range from no impact to a significant improvement of using Agile methodologies over, say, waterfall processes. This large variability is a hint of how inconsistent these studies are, but I've seen more evidence piling up in the "good" side of the scale.
However, from your loaded comment seems clear you aren't really interested in data anyway.
The parts I didn't think worked:
* Retrospectives which had no actions as an outcome
* Daily stand ups that were led by a project manager who discussed each persons work 1 to 1 within the group
* Bugs not really fitting into the flow of work
* A poor planning session can set up a bad sprint
* Sprints often ending without any working software
* Team members working in silos
* Outside dependencies blocking work
* Estimating turning into 'how many hours will this take?'
* People reporting working on two or three things every standup
* and the worst imo, work not on the sprint board that must be done
You need to take in consideration what scrum makes you do (stand up meeting,...) but also what it is meant to prevent and you shouldn't usually do (interruptions and working on requirements that change daily)
It's hard but when done properly it's great
The cons are it's a huge waste of my time.
I much prefer a system where someone just tells me what they want/expect, and leaves me alone while I do it.
I have no idea how tracking should be done.
What I’ve seen work best is just a quick “hey this is what I’m doing today/this week, will depend on yyy” so that anyone who depends on what you’re doing (or not doing) knows; alternatively, “wait, you’re depending on my project yyy?”, no discussion except, “hey, let’s talk directly after this”.
Not for any manager’s benefit, just for each others’. Like a code review there should be no judgement. If anybody wants discussion do it elsewhere so everybody else can get on with things.
Also, the bean counters have won. In most enterprise companies "Agile" is nothing more than top down micromanagement.
SCRUM/AGILE/whatever for development and product teams is a red flag for me. I find that bi-weekly demo days seem to set a better culture and pace for things without the constant oversight.
Sprinkle in some weekly "forums" across teams to chat, BS, and discuss issues. Invite people to bring their agenda questions, concerns, etc.
The biggest thing (especially in remote) is that all your humans have visibility to the other humans in a semi-consistent basis. The org-chart matters.
but we dropped that bullshit like "story points" - you know, abstraction over abstraction of time/effort whatever it is.
we estimate stuff in man hours.
However, it is essential to keep in mind why these things are done and not just cargo cult them.
I have felt Scrum is cargo cult agile which helps non technical managers retain power post "agile transformation" in the form of "scrum master". Just that title changes the power balance in meetings and kills the spirit of what they are meant for.
To make a meeting matter, make a decision. You can make the daily stand up ritual into something meaningful to the participants, if you recast it as “let’s decide what we’re gonna do today.” If it is just a progress update, then it can be done better asynchronously.
But, the daily stand up actually does increase productivity as a status update, if the work is not planned out properly. So let me get into what that means: in theory, on any software project, there is a dependency graph of steps which have to be done in order to achieve the next release. This graph also has implicit dependencies just because we have finite resources and one person can't do everything at once. The steps also come with some time estimate, and then we know that there is uncertainty in that estimate so we add safety buffer. Whether the work is planned out properly comes down to whether this safety buffer is spent, or squandered. If the most important thing is not being worked on, if it is sitting waiting for review say, or if it is just an ugly messy task that nobody wants to pick up: then your safety buffer is getting spent but you're not getting much for it. And the easiest place that this happens is at the start of a new release when there seems to be so much abundant safety buffer that it is now time to play and relax and experiment with random ideas. In fact, give arbitrary amounts of safety buffer to a poorly planned software project, and it will overrun whatever buffer you give it, simply because of this lack of urgency at the start, it becomes even less urgent if it's not due in one quarter but is instead due in three quarters.
So that is where standup comes in and imposes an artificial urgency. And somebody randomly happens to work on the critical path and it starts moving forward. Until you run into a big ugly problem that nobody wants to solve on the critical path, then the project gets delayed until there are no other things to work on, someone has to slog through the pain. you still miss the deadline but not by nearly as much as you were. Lights a candle under everyone's ass. It's not the right approach, the right approach would light a bonfire under one person's ass, the exact right person's ass, until they passed the baton to the next person.
No methodology works right out of the box and it’s insane to think that any could. You have to look at your specific requirements and mold Agile around your team. Agile literally says to do this but most just ignore it.
The more thought you put into your methodology, the better it will work. I know most want Agile to replace critical thought because they don’t want to have a target on their back if things go wrong but there is no substitute.
Scrum is a gimmick invented to sell scrum courses. It's an easy-to-understand framework for convincing managers that their teams are agile, but I've never seen it work in practice.
Some of the scrum practices - such as daily strandups - can be extremely valuable for software teams. Standups, for example, are an opportunity for alignment, or more accurately, for correcting misalignment. And like all practices, they can be practiced badly.
So by having each Sprint accounted for and signed off, whenever he barged in and demanded something new, the first question was asked - what would he like removed from the current Sprint. By him signing off that things were removed, he could no longer ask why it wasn’t completed as originally agreed to
I've subsequently seen agile/scrum very poorly several times within both large and small companies.
I like working within Agile/Scrum - when it's implemented well. But that's rare.
The ideas behind agility in software development were all about reducing bureaucracy, focusing on small slices straight to the customer, strong focus on quality and testing practices and continually readjusting and improving. None of it was ever about stand ups, estimation, using Jira etc.
We do:
- sprints
- retrospectives
- healthchecks (from Spotify squads)
- story points, and kinda compute our velocity. Well, we approximately know how many points we can do in a sprint
- say no. We routinely refuse to do stuff coming from the top of it doesn't align with our vision as engineers
We stopped:
- daily stand-ups. They're completely useless
- poker planning. We still evaluate tasks together but without the useless ceremonial, and autonomously reevaluate during the sprint if necessary. It's considered bad, we don't care, it works.
Sounds you would like proof that scrum does not work. Instead, how about looking at the parts that could work for your team, and discuss if you should adopt?
When we need a bit more torque, we tend to adapt more process and when we have plenty of time to waste we abandon process and take it easy.
If you are lazy and dont want to work, you probably dont want processes that expose your slack.
And it also depends on how you implement it - doing it well relies on buy-in from anyone touching the dev team in any way.
So, yes it can offer benefits, for some companies, if done well.
Just renaming managers into product owners and renaming hour long meetings where you explain yourself to the manager "stand-up" is not going to get you anywhere. Doing it right involves significant change to process with no-one trying to circumvent it.
Standups aren't supposed to be about managing, there is no manager present. Ours takes 5 to 10 minutes before lunch.
However Scrum has become so formalised, so focused on certifications and titles and the exact way to do it, that it's become the opposite of what Agile was trying to achieve.
The practice varies, if done correctly it's beneficial, if done poorly it's a nightmare like any poor software engineering practice. Can't tell you definitively about how beneficial it is to the software industry, but I believe it's a net positive since it has encouraged faster shipment over big bang releases.
Most people aren’t doing agile, they’re doing a custom, lightweight version of it. This is a good practice though I still think it hurts projects; but not as much as quote unquote real agile.”
Can you make it a poll? That would be really interesting
Oh, a few months passed?
Define Agile/Scrum again, because one of the key decision makers has moved to a different role, so we’re changing things. So what’s the new definition?
Oh, some more time passed?
More org changes! Time to change the definition of Agile/Scrum again.
Now, what was the question?
“Well if you’re doing it right, it should survive though changes of management.”
Oh ok, but tell me... when did that assumption ever hold?
Cons of any product development process is not taking into account human interaction and assuming a perfect team.
Build a team first, choose process to get the best out of this team be it Agile/whatever.
But a good agile team will be more responsive to changing customer needs.
Sprints: What are the pros and cons of delivering working software incrementally at regular intervals?
Standups: What are the pros and cons of teams members spending 15 minutes together every day talking about their work and how they might help each other?
That's what I want to believe anyways.
It would be interesting to see an actual study, though.
Team A does project 1 with Scrum.
Team B does project 1 without Scrum.
Let's say over 3 months.
Who wins?
We could look at time to finish, bugs, code quality/resilience, etc.
I know there is a 'study' out every other day from some Project Mgmt org saying, "500% of IT Projects are fail!", but obviously we need real studies.
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan" -- Agile Manifesto
Whatever we do in agile/scrum of Today is anything but that.
I am curious to know if Teslas/SpaceXes/Googles/Stripes of the world practice Agile/Scrum?
Like with any great idea there was someone who decided to monetize it. Thats how scrum was born.
I see that with every pragmatic solution good devs try to share:
- TDD
- Agile
- FP
Sooner or later some “hot-shot” shows up and decides to “teach” ppl for money “how to do things correct way”.
After that great ideas turn into crap, because too many people want profit from it instead of learning from it.
Pros: helps team uncover and jump over costly roadblocks Cons: overhead
There’s probably a better system out there. Till someone invents it, Scrum works fine for my teams
Many places also do agile badly. The ones that have stand ups without a (certified) scrum master are likely doing it wrong and can often be anti-productive.
Kanban is fine though, and a good low overhead technique for multiple people in a team.
I’ve often seen coders staring at the void during so-called standups, and very weak devs closing tickets while doing almost nothing useful for the project, because their managers cared only for this metric...
Scrum, management, meetings distract at best, crush at worst, this critical creative process.
If done properly (very rarely done properly) it works as described on the box.
Most people simple use Agile as a way to generate interactive Gantt Charts that management can change willy-nilly. It's very rarely done to empower teams or improve effectiveness.
We are trying to build a new way of building value - this time using code as technology. My usual comparator is this is software literacy - and we need to look at the effects of the European literacy explosion of 1450's as a guide (renaissance Italy still kept glassblowers as virtual prisoners)
The things that are broken and I think in need of change
* Capital vs Management. Executives often capture too much value, and control too many of the allocation decisions. Huge corporations are inefficient - in a similar scale to centrally planned economies. (For example, I cannot imagine that Jeff Bezos spending billions on rockets is the most efficient means to produce value from those billions)
* command and control vs democracy. Again with the decisions best taken at small scale. How would your (big) company behave if instead of executives deciding which projects got what funding, it was voted upon by employees? It would be radically different. Would it be better? I imagine the discussion forums would look a lot like Linus' rants. How would we moderate that? Would hiring people be different? Would you hire someone politically different to you if they might vote against you? Would you even get a hiring decision?
* Project Management stops being about dates. This bugs me a lot - at some point all the nice agile - we need certain level of quality, story points are a measure of complexity not time, we discover as we go, all that falls apart and becomes a date in a plan at the board level. Mostly because the tools used at board level (and the mental models) cannot cope with ideas of alpha, beta, prod quality, or if this date slips all other dates slip too - cones of uncertainty are a good approach to this, as are other mapping functions about the relationships between features and capabiites. I dont have a good answer here either.
But there is a lot going on - its not a fad (ok Scrum might be, but this is not about scrum - or agile - its about how do we humans produce this new code thing at scale and change our society around it as we did in 1450 with words, or 1890 with cars.
If you have the skill to write code, then dismissing this as "management crap" means giving up an informed voice on one of humanities most important inflexion points since ... the last one.
Whatever you do, make sure you review all procedures to decide if they make sense for your team. Don’t follow them blindly.
Kanban is an approach with less ceremony.
I wasn't the only person that left.
The Agile manifesto doesn't talk about roles or how the process should be, but Scrum does it.
Agile itself was introduced by bunch of software engineers came up with the Agile manifesto. It's simple, abstract, and effective. There are many successful tech companies that already have something more extensive than Agile. Agile manifesto is just a good starting point if you don't have anything in place.
But somehow Scrum became the recipe to implement Agile and we ended up with a job title called Scrum Master which has been increasingly taken by non technical people inside traditional organizations.
I've seen teams that implement Scrum by the book. They have a person called Scrum Master that facilitates all team meetings. It basically turns other team members into reactive players instead of proactive. But, do we really need a person to facilitate team meetings and ceremonies?
I talked with a few Scrum Masters, their job satisfaction is actually very low and even though they don't admit it to their own team, they don't believe they are adding real value. What they all have in common is that they all want to switch to a different role and they are looking for an opportunity.
I couldn’t find anything similar in other industries, and it's hard to find a successful development team that implements Scrum by the book. What you find most of the time is what is called "other Scrum flavors" and I think that's a problem in our industry. What many teams are doing isn't Scrum, but anything that has a short release cycle, a daily update in any form, and a retrospective is called Scrum.
The irony is that most of the Silicon Valley and successful tech companies don't use Scrum at all. In fact many of them don't even label what they have as Agile.
What is happening right now is many companies wasting lots of time trying to implement Scrum by the book until they fail and move on to something that they call a Scrum flavor. I think we should stop calling it Scrum so others don't have to repeat the same mistake again and again.
If a team fails, Scrum compares it to its book and says the team failed because they didn't implement Scrum properly. And when a team with one of those so-called "Scrum flavors" is successful, Scrum takes all the credit.
I personally think we should kill Scrum. We shouldn't advocate it and we shouldn't call any team with a daily update a Scrum team. Many successful tech companies don't use Scrum, but they aren't vocal about it.
A good agile process, make development work less stress.
For experimental stuff, agile could be good.
For product stuff, Scrum could be good.
For commodity stuff, six sigma could be good.
Using one of these for something it isn't meant to do will lead to failure.
Standup is a status meeting? Who told you that? It's a planning meeting. You plan the day with your peers. If you do it right you don't have to talk to anyone the rest of the day and just flow.
Don't listen to the consultants. Learn about real scrum from here. https://sites.google.com/a/scrumplop.org/published-patterns/...
Tickets come flying in, blockers get turned into a mountain from a mole hill, planning meetings are multi-hour time wasters, retrospectives cover the same things, and everybody is just nice to each other rather than raising their concerns. Deadlines are a fallacy, other than giving substance to these ritual meetings.
Kanban makes so much more sense. Allows estimation via cycle time
What bothers me is that scrum masters are being groomed as the next-gen MBA.
too much chin wagging, not enough building too much synchronous communication
for being called agile you don't build software very quickly with it
As you note, disadvantages include micromanagement and perverse incentives.
That is to say, in a lot of ways a small clever theologically-aligned team is going to be better. But if there’s a good reason you can’t have that, scrum can help you make the most of it.
Unfortunately I've been working in backend data movement since college where the final product is very well defined in the old waterfall model. Our intermediate tables aren't any use to the internal customers and there's not really much iteration needed, they come to us with data that's somewhere other than where they need it and we bring it to where they do. Recently though our org has taken to Agile/Scrum and the results are a little painful especially with our projects that require significant infrastructure setup, all of which is owned by external teams often understaffed so their backlogs are weeks to months long and while we're waiting on provisioning or approval from governance we're stuck looking for stuff to do that will meaningfully move things forward.
For engineering and software quality? Absolutely not.
The rest is just a religion.
I had mixed experiences with it but absorbed a lot of good lessons. While I can't speak to "scrum" that much (I've seen degraded forms of it a few times but not the actual "real" thing) I think many of those fundamentals have been lost in the intervening years... err.. decades (cry).
Two things key for me, that it seems that people don't care about anymore:
i. Developers doing their own estimates. Absolutely essential to managing scope. This one always goes out the window or gets ignored first. I have worked in so many "agile" teams that would choke on their own vomit before taking the power away from managers or "experts" on the team to decide how long something will take. If this is the case, there is no point in scoping in an "agile" process anymore. You'll just have to crunch to meet their deadline, and that's that. That's not "agile" that's "sweatshop." (Or, if you routinely blow out / pad the estimates too large to compensate... inefficient)
ii. Ship the minimal viable product, and then iterate on it. You ain't gonna need it, etc. Release frequently and often and in small chunks. Absolutely foreign concept to most of the recent UX and PMs I've worked with, especially at BigCo, who treat the design doc / mock / spec as the finished product, with the actual development just being a kind of "last mile." Want to know what changed between their last giant spec document and now? Read the whole 50 pager again. My wife was taking UX design courses and even there, while paying lip service to agile there was all this type of "produce a planning document" with big upfront information hierarchies and total project design. And yes, even working in embedded and other things not front facing, I found this to some degree. A fear of iteration, still. The act of forcing the customer or PM or whatever into a discipline of an incremental thought process honestly helps with frequent delivery, and keeps the process responsible to the user, the real final customer.
What is so often missed is that agile in the classic XP sense was an exchange, some compromises: I (the engineer) agree to work rapidly and ship frequently and to give you great visibility, but you (the customer) agree to be provide me with constant feedback and prioritization, to accept my estimates/scoping, and to think incrementally and practically about what you want now rather than what you think you might need 6 months from now.
Daily standups and iteration meetings and story cards? Handy. But these are just part of the mechanics and can easily devolve into theatre or pantomime of "agile" if the other pieces aren't there.
I've worked on scrum and other types of agile project management over the last ten years. In that time, I've seen many bad implementations and only one good one. At Redbox, they had it down to a science and it worked perfectly. They had meetings for developing stories run by business analysts. They had sprint planning meetings run by scrum masters that only involved fully vetted and story-pointed stories. They used Fibonacci numbers for voting and everyone had a vote, including the QA people. They had QA people! We only started a sprint if everyone agreed on the stories. We (the developers) selected stories. We were never assigned anything. Stand ups were very quick. What are you working on, what did you complete, do you have any blockers.
The entire point of agile/scrum is transparency and to focus on delivering incremental value. Over time, that value can be packaged and reported upward to show management what features are being added or improved. No one can hide. If you're not pulling your weight or invested in your work, everyone will know within a day or two. If you legitimately have issues with your assignment, you need to communicate that and the team will help you.
The issue that comes up over and over with agile/scrum is how management and budgeting interact with the backlog and prioritization. There is often zero trust from the people writing the checks on "incremental continuous delivery". They want feature X boxed and completed by an arbitrary date. In my experience this _always_ fails. What you end up seeing is "something" being delivered by that date, but with an "acceptable" number of "defects". Which is to say the entire feature isn't really complete and everyone has agreed to lie about that fact.
So continuous delivery via an agile process is the only way to do the work and make sure things stay on the rails. The harder problem is getting people in management circles to understand this process and embrace it and set aside their old school project success reporting techniques.
Like I said. In ten years I've only seen this done well once. And then a few places did it "okay". Most places do what everyone laughingly calls "fake agile", which is a mix of waterfall and agile.
Don't get me started on things like SAFe or Pivotal. Those are ways of putting process behind agile and that breaks one of the primary tenets of agile. People over Process. It's also clearly an attempt to monetize agile through testing and certification or by putting an app in front of it.
Regarding the "standups", for example, they are definitely not meant to be about "micro-managing", "signalling process" or any kind of "status report" (definitely not to a manager!). The idea behind these kind of agile methodologies is to allow teams to self-organize. The standups are meant to be a brief way for the team members to catch up with each other, and seek help if necessary. There's no need to say anything if you don't feel that you need to sync with your team members, and it's definitely a way for managers to control what you are doing. When done right, they are short, concise, helpful and positive. The same idea applies to the "retrospectives". Don't call them that if you don't want, but it helps to get together as a team and see what you want to change in the current "way of doing things" - and it's good to actually have the autonomy to change it!...
About the concept of "sprints". Dividing work in sprints is both about planning and, again, about self-organization. It's about fairness in a way: leaving developers the time to deliver something, in a way, "protected" from route changes and with a clear goal of something to deliver. But it's also about not setting up goals too far in the future. Because the goal is set up in (usually) a couple of weeks time, the results can be analyzed and the product, or whatever, developed incrementally, with management reviewing the progress bi-weekly. You wouldn't want to set a goal three months in advance and discover at the end of that period all the things that you assumed were one way that were actually not that way.
"Agile" touches several points and one of them is that during work it's important to talk face-to-face about requirements and how whatever you are building is meant to work. That is, as others have commented in this thread, that it's a good thing to have a conversation during development with whoever is the representative of the product side of things to solve doubts, instead of relying on a list of requirements.
That's, from my point of view, less bureaucratic than a formal process. The regular meetings are also meant to be lightweight and to the point. You don't have to have a highly formalized process to "point" tasks. The underlying idea is to try to allocate a reasonable amount of work to a certain period. That also does not mean that bugs or unexpected issues can't be fixed during the sprint - there are ways to make all that work.
You have to understand what all these practices are for, the ideas behind the whole thing, to do them right. And you have to work with people that behave in a certain way, that have a certain good will, that have a certain working culture, the righ experience, etc. The particular circumstances will make all the difference.
I think that seeing some of the answers in this thread it seems a little bit discouraging, but, in my humble opinion, one just have to be lucky, find the right company and the right people to work with. I hope that my personal perspective helps.
First of all, I would like to address the "haters". They rant on and on about how Scrum does not work, how its slowing them, unnecessary meetings, etc. But if you look at what they say, it's always the same. They screw up, did not used it correctly. Its like when you want to cook a dinner, and burn yourself instead. Do you blame the fire? Or your stupid ass? :D
Scrum is not a silver bullet. It is not useful everywhere. For example for very small teams, who have like one, standalone responsibility, they know it well,... having Scrum is a waste. All they need is someone who will be able to give them (feature) request and they will do the job well. They are essentially self-organized.
However, for bigger teams, more complex product, more teams involved, this does not work anymore. One guys can THINK he is the owner because he coded that particular component, but there is another owner in second team and they clash. Often times people work like crazy, but the whole product does not work. All the pieces are there, but they cannot work together, gazillion ideas how to make it work, ego-driven heated discussion how we should use this library instead of this one. How everyone else is stupid because they do not integrate with us first, etc.
Scrum it is NOT a waste of time. Any fool that say a 3-4 hours during two weeks is great waste is total junior. That amount of time will never ever mean difference between "job well done" and "oh no, we fucked up again". If you are desperately thinking that the extra hour you spend coding instead of 4 daily standups (15 minute each) will save your product, then you already are on the edge of "crunch time" and doing something incredibly wrong.
Scrum - when implemented properly - provides many benefits:
1) Little to none micromanaging: The amount of micromanaging and reporting is lower, because your progress is visible without the need to actually report to the boss.
2) More option for your own time schedule: If the team evaluates that something is "hard" and give it huge number of storypoints (if you use SP), you are expected to work on it for some time and no-one will bother you like every half a day.
3) Predictability: business oriented people can easily "calculate" the time of delivery based on your predictions/estimates. You are shielded from that bullshit AND you are earning more trust every iteration, which means you have more option to do it your way.
4) Knowledge is shared: there are no silos, everyone potentially can work on anything within the competence area of the team. If someone gets sick, work just don't stop because the "owner" of the lib is out and we know nothing about it.
5) The power to stand up to the brass.
And others, I personally value those the most. And you can achieve some of those using different frameworks, but Scrum is proven to work the best all around. Also important note is that there are some basic rules for Scrum, but most of it is just recommendations. If you follow the book to the letter and do not adjust for your team, you are screwing yourselves.
The point is, "agile" emerged from accepting that building new things primarily deals with the uncertain. You plan something, and then there are the "unknown unknowns" where things will take orders of magnitude more time than planned. Additionally, more often than not it isn't even clear how the solution actually looks like or if the stakeholders even articulated what their real problem is. So the solution: just start with something and then establish a short feedback cycle to steer the next steps in the right direction, which wasn't obvious in the previous cycle. Therefore all the ceremony, like doing daily standups to resolve problems that arrive while iterating the problem space, or retro/review where progress gets presented and the next steps are agreed upon. The heart of the principle translates to "be flexible" in the face of uncertainity. This also implies that the team is trusted to decide on the spot.
In reality, "Agile" often comes in the form of something like "Scrum", which isn't agile at all. There is ceremony and cargo-culting how one should behave without any understanding _why_ to do things. Management gets sold the idea that they get a tight grip on all decisions (Micromanagement) and can closely "watch how workers perform" with a short feedback loop. Because "we cross the bridge when we come to it", all the "engineering" parts of software development are thrown out of the window and essential things like caring about sound architectures/maintainability/... are supressed. This gets even more emphasized with the usual mindset of "Velocity", translating to managers as "build more features faster, now!". This in turn leads to some early successes but mostly turns into swamps of unmaintainable glue code and after a while the voices wanting a "rewrite" become louder... back to square one. Oh, and do not forget that "Backlogs" (especially with months/years ahead planned and communicated with stakeholders) are just chunked Waterfall processes without any flexibility, ironically killing actual flexibility. Daily standups become just virtue signalling happenings where everyone agrees that they're "on schedule" or "things will take longer".
There ARE teams that deliver high-quality solutions without getting slower over time using Scrum, but know what? These teams would achieve the same with any process, including some internal Waterfall variations. Great/experienced people deliver great results, even more so if they can act autonomously.
So instead of some magical "Agile Processes" that everyone has to follow and great results will appear (in reality: they won't), my job is to increase the chances for actual success in the real world. How? by following some LEAN values (instead of processes). But here is the next catch: there are huge misunderstandings about LEAN when it comes to software development!
Classical "LEAN Production" comes from a world where physical things are manufactured in large numbers, basically doing the same thing again and again, and tries to optimize how to do this thing better/faster/cheaper. In software development the root problem is inversed: we are never actually doing the _same thing_ more than once (except cases of reinventing the wheel). All attempts to use classical LEAN Production techniques to software projects will fail miserably (except you have awesome people to begin with, see above).
Then there are the "Lean Startup" people which start with the actual problem space and cycle in "build measure learn". Makes absolute sense if you are a startup and have to find _something_ that sticks. The problem: teams that act like this are doing the job of actual business founders and require the trust to change the business itself. This doesn't work within a traditional company when you have executive teams and a management hierarchy.
So what could be done if these things don't work? Dig deeper and formulate _values_ everyone should follow. Examples:
- "decide as late as possible" -> do not lock yourself in hard technical dependencies (this will only run with MariaDB v123 on Google Cloud with Setup ABC) early on, or else you will have a hard time being flexible (like migrating to AWS Lambda because some compelling technical/business reasons). Yes this way is not able to leverage minute features of a ultra specialized solution, but chances are high something generic will do (like: we need a sql database)
- "build quality in" -> in many cases it does _not_ take significantly longer to build something that is well-tested, decoupled and documented than to hack something together, especially when you are building it right now and have all requirements in your head currently. In fact, most code that is designed with maintainability is more on the side of an asset (you can build on it) instead of a liability (should be replaced in the future/does not get used because noone understands it or its purpose/... bitrot.). So when your building blocks are actually solid, you may even become faster, which often shows in mere _weeks_ after a project starts.
- "Eliminate Waste" -> the posterchild value of LEAN... but the quintessence. Everything that prevents the team/individual to make relevant progress right now must be stopped. Relevant progress is anything that produces value for the customer (read: _not manager_!). Waiting hours for feedback if a code snippet works? Make it fast. Sitting in pointless meetings or ceremony processes? Cancel them. Deployments/Builds need mental energy to execute? Automate it. "Feature Ideas" from managers? Let them prove that it WILL bring customer value, ideally: how much. Can't stress this enough: do not build anything that does not clearly increase customer value, no matter who demands it internally, never follow the "what if..." rabbit hole or you end in feature creep and potentially dead code areas that still cost maintenance.
... and so on. You can google more infos about "LEAN Software principles: if you want. The main takeaway: act based on clearly defined values _enables_ actual agility, acting based on arbitrary processes (like Scrumfall) _decreases_ actual aglity.
But even this (my) approach has a big downside: success is measured in ... success. Whatever the Team does, they must show that there is a measurable business impact, or share why something failed (so that bad ideas will not get tried again later... and again...). This is a stark contrast to the "virtue ethics" approach many are happy with, where "trying with best (displayable) effort" is good enough and gets rewarded. I will just look at the outcome: what did you do, was it executed as good as possible within given constraints, and which impact did it have, followed by the question: what did you learn and therefore what is the next logical step?
Many people still prefer to work without the "pressure for success" for 8 hours per workday and go home, where working is just the thing one does for earning money. No issues with that, but chances are even LEAN will not work when you only have people with this mindset. Not disciminating, just my experience.
- don’t mix up Agile with Scrum...
- see Agile as aspirational (aka read an try very hard to go back to the manifesto to clear the clutter)
- see Scrum and XP as tools
- prefer XP to Scrum : yes, it’s better to have good software in the middle of a shitty process than a good process around a shitty software. believe me, good software, even in nightmarish organization can bring joy. don’t be the opposite. :-)
- be concerned about the internal well oiling of the team first and the the product: same than with the process, a good team can course-correct a bad product decision or a user backslash (to a point), the opposite is way harder...imaging trying to keep your users telling them your product is superb, it’s just that the software works half of the time...
For the’code part’
XP if you can/know, or just start with automation (basic ci/cd or cr, tests). Then raise collaboration by making it easier to ‘code together’, agree on ‘code expectations’ and communications expectations whatever that means for your lot. THEN everybody should approach their ‘quality standard threshold’. The way is just up from there: code coverage, TDD/BDD, code review, IaC, you’re already pretty ‘software agile’ at that point, but like a circus artist, reach for always more agile
Next the ‘product part’:
That’s where most Scrum consultant will hammer you with the dailys, the demos, the ceremonies and all. Back to the manifesto. Learn what your people like, what and when it makes them productive. Make it weird, unwieldy but a perfect-fit for you all.
If a consultant looked at it, it should say ‘oh, ok, that’s a weird way to do it, but I guess it could work’.
To put my money where my mouth is, here is what we do (but it’s full of our remote, bilingual, socially multi-diverse quirks).
We start and end at a demo to our C-level and business ‘patron’.
Just after the ‘last one’, we pick what we will try to demo next time. We talk about the value of it. To whom in our demo audience/user it should evoke excitement. What would be ‘minimum’ otherwise we dont show up. What would be ‘nice’ and what would be mind-blowing. We all agree what a user should see. We settle on it for the next weeks (yes, no prefixed date). In general there’s one or two ‘big things’ that would constitute ‘the meat’, we create one/two sufficiently descriptive stories with personas that should match what we discussed for the demo and Condition of Success in JIRA and put it as In Progress. Everything else, except production issues, is considered unimportant and optional. If one of us has time during build or waiting for a review, we tackle the ‘little things’.
The PO/Business DoppleGanger goes get what we need to do all that (wireframe, design, translation, legal wording, marketing spiel,...). He/She works directly with the devs that need it. We meet every Thu and Fri for 5/10 min (usualy, max 30) entirely to make sure sub-groups or individuals are not missing on what other will be doing and profit from it. We talk about what we’re working on next not the past (the past is done, stop wasting time talking about it!!! :-)). No task, no story bs, no past ‘blocker’ discussion lingering. If people want to track their stuff in github issues or JIRA, they do it on their own. But they better make sure it’s tidy and up to date cause we do not accept messy backlogs.
In between those ‘bi-weeklies’ if someone in the team need to discuss anything or are blocked, they shout on Slack and wait. If it’s an emergency, they send a mean Giphy. If they really need someone, they DM a lead. and so on. People own what/how/when they do 200% up until we approach the end of the 2 week threshold.
Then it’s about all that we achieved. The big question is asked ‘are we ready to demo’? If a majority don’t think we have enough to show, we wait another week and ask the same question. Then week 4, same. At that point we need to have a freaking good reason not to be showing something after 4 weeks. Even if it’s minimal. Even if it’s a bunch of HTTP calls and some JSON.
And we cycle.
In summary:
- 2 meeting of max 30 min (you can drop of after that)
- lots of behind the scene ‘ad-hoc’ interactions per need (that respect a ‘rule of engagement for collaboration’ the team agreed on, btw)
- 1 demo, tailor-made to the actual delivered value by the team (not the dreamt one) every 2, 3 or 4 weeks
Practice wise: IaC all the way (tks Pulumi and Google Cloud team), CI/CD (with real automated delivery not CR), code-review using PR and on-demand env, fully diamond-shaped code coverage, dependabots and automated CodeSec audits, conventional commits with semantic versioning, and we’re just starting.
-> No planning (except the 40 min discussing the next demo just after the current one).
-> No poker estimate. In fact no estimates.
-> No backlog burn downs and cycle time and resolution time...
-> No WIP (technically, yes, this is Scrumban-ish with a WIP of 2...).
We do one quarterly product vision discussion with everybody that feeds team growth and high level product roadmap (no precise estimates, in terms of Q or 2 month span).
That, I believe, can be called agile :-)
In the most common case I've seen, Scrum quickly devolves into Scrum-flavored micromanagement by some combination of actual managers, business teams and "product owners". Short sprints, daily tracked tickets, process-based decision-making... all effective at taking away autonomy from the people doing the actual work.
Even if you avoid the worst sort of micromanagement, though, Scrum still has fundamental problems. The process is primarily team-oriented, which sounds great until you realize that it's creating strong psychological incentives through peer pressure—and they're the wrong incentives. Standups, Sprint Planning, velocity... etc all push people to hyper-focus on small tickets with tight deadlines without considering the broader context.
I've seen this create massive problems on teams:
1. People feel siloed on their "assigned" tickets. Having constant public deadlines means that everyone feels pressured to make visible progress on "their" work which actively stifles ad hoc collaboration. On Scrum teams, I see people guilty for asking their teammates for help!
2. For the same reasons as 1, people feel pressure not to work on anything that isn't "their" ticket. In my experience, the best way to maintain a quality codebase is for everyone to fix small problems as soon as they see them; while this is possible with some Scrum implementations, you're fighting the current. This also robs people of any ownership over their work or their code, which is another key component to quality software development.
3. Scrum incentivizes consistency above everything else, whether impact, progress or work quality. Teams get bogged down with technical debt that accumulates gradually enough for estimates to adjust, but they continue to look productive anyway. After all, slow, incremental progress is actually more consistent than fast bursty progress!
4. The nature of the processes pushes individuals away from understanding the broader context of their work, and encourages managers/product owners/etc to communicate at the wrong level of granularity. Instead of giving programmers the context they need to make effective tactical decisions, Scrum pushes for trying to adjust work through small, artificial tickets. Too much information flows from the team and not enough to the team. I've seen managers get annoyed that their programmers don't seem to care or understand the broader context of their work—where's the passion!?—but how is anyone going to understand or value context if they don't have the space to make any real decisions with it?
5. Constant public deadlines absolutely destroy psychological safety. The teams I've worked with using Scrum are consistently under more stress than other teams. It's no surprise—needing to show up to a standup every morning to say "I'm still working on X" is pretty depressing, no matter how much impact you may have in absolute terms. The process provides plenty of ways for programmers to feel like they're falling behind or letting the team down, and provides no real upside. There's little room for real creativity or agency within a heavily process- and ticket-driven system; the best you can hope for is doing your assignments faster. How can anyone really excel in that sort of setting?
I've been working in Target's AI/data science team for almost five years now, and I've worked on and with teams that were heavily into Scrum, teams that didn't treat it too seriously and teams that operated with minimal-to-nonexistant processes. Some Scrum teams did okay and some were complete trainwrecks. Much lower-process teams weren't always great themselves—there are a lot of ways to bog down software development!—but each of the most productive and innovative teams I worked with was on the low-process part of the spectrum, and people working on those teams were noticeably happier.
At this point I've spent enough time both observing and thinking about Scrum-style processes to have some strong conclusions:
1. Process imposed from the outside is usually awful. Scrum especially so.
2. Process legitimately adopted by a team can be okay—even Scrum—but still has a real chance of backfiring. Scrum especially so.
3. You don't need process for poor management, but the two seem to go hand-in-hand.
4. The best teams have leaders—formal or not—who effectively communicate context, motivation and direction then leave room for individuals to figure out how to get there and how to communicate up about it.
Now the challenge is how to help incubate environments like this myself, and how to judge whether future teams and companies have a culture like this or not.
Agile is the recognition that that in the modern world, especially in digital products, we learn new information faster than we can act on new information, and so we benefit from structures and "processes" that allow us to discover and act on information as quickly as possible. "Processes" is in quotes there because this usually translates to a _lack_ of process. Formalized process slows things down and agile wants to act fast. Agile prefers for us to live and communicate in the moment rather than through some structured form. This is also why agile tends to be a bottom-up organizational structure, giving the most agency to the people doing the work rather than managers and middlemen.
Scrum is weird, and very, _very_ misunderstood. Scrum, at its heart, is trying compensate for one of agile's "weaknesses"--or at least, what many organizations might view as a weakness: disempowered management. Most organizations aren't willing to adopt the agile values that allow them to move fast because it means higher ups have less direct control and visibility into what's going on. Scrum tries to compensate for this by introducing an agile-flavored framework that isn't really agile, but can provide organizations that won't adopt agile values with structure that can still give them a bit of what they want (namely visibility) while providing some of agile's benefits.
Scrum's Achilles Heel, however, is a tragic one: Organizations that aren't willing to adopt agile's values aren't likely to adopt Scrum's values either. So despite all the effort and "restructuring" organizations put into place to "do Scrum", they end up with the same values and processes they were already using, but now with a Scrum-like vocabulary. This is why Scrum gets a pretty bad reputation: At its best, it's not as good as agile, and at its worst, it's twisted into a mask for the processes that were the original problem. You're usually better off either doing straight agile or not bothering with either.
As for the pros and cons of the concepts and meetings, let's clear up what each of them is about:
Standup - Often used as a daily check in. This not the intended usage and doesn't do the team much good. A well-used standup is simply an opportunity for team members to expose any blockers they're encountering so that others might jump in and help if they're so able. If the team has good communication habits already, a daily stand up won't bring them much benefit. That said, it's also serves as an opportunity for shy team members, or those who don't want to bother people, to regularly get a chance at communicating their problems, so it can be practical depending on the team's personalities.
The Sprint - Most teams think of the sprint as a unit of time around which they should plan work. This is incorrect; in fast paced environment, there's no such thing as planning work reliably enough that you can assign just enough for the sprint's duration. There are too many unknown unknowns for that to work.
A sprint is the maximum amount of time the team goes between syncs about the priorities, current problems, and what works needs to be done. Sprints aren't about planning out work and getting to it, they're about making sure the team regularly aligns itself on the important things. To accomplish this, we usually have two meetings per sprint:
Grooming - A session in which the team comes together and reviews all the upcoming work, changes, etc. The goal is for everyone on the team to be familiar with what's being worked on, how the product should behave, and that product definitions/specs are clear enough for work to begin.
Retro - A session in which the team can explore organizational or other obstacles getting in the way of productivity, and then collaborate on solutions to these problems.
Checkmarks, point systems, velocity tracking--these do not contribute to productivity and are not worth incorporating into your team. Usually, the people that benefit from these are not the people who benefit from productivity, but the people who want to have "data" they can use to prove to _their_ manager that they're doing a good job (and deserve a raise/promotion).
There's a lot of depth to agile, and done properly it can be a huge boost to fast-moving teams. But it's also very easy to get lost and go down a bad road that satisfies no one. Agile is worth pursuing, but only if you have a good guide that can keep you on the right path, and the full buy in of the organization, so they don't pull out on you halfway through.
Credentials: I'm a certified level 1 Scrum master.
You cannot fix bad management or ineffective teams by applying a methodology, and many companies have both broken management and broken teams. Sprinkling “Scrum” on top won’t fix that, and there’s a widespread failure to realise that the symptoms people see are not the result of Scrum or Agile or anything else, but would exist regardless of the development process being used.
So, for example of how I find this working well: total process overhead for my teams is about two hours a week, averaged over the two-week sprint. This incorporates all of the planning, reviews, and daily standups. Outside of rare or one-off events like project kickoffs, post-mortems, or long-term roadmap discussions there are no other process-related meetings.
Daily standups are very much a “good morning” meeting to say hello, discuss plans for the day, and make arrangements with anyone who wants to team up or get some input from others. 10 minutes maximum. Development team and product owner only.
Fortnightly review meetings are the chance for all of the teams to get together and briefly talk though what they’ve been working on, since they don’t necessarily interact with each other all the time. This is a good chance to highlight anything that might affect others or ask any questions. 30 minutes with all the teams, including business development, management etc.
The retrospective is a chance to flag up and discuss any general issues or ideas - maybe proposing spending some time on fixing a frustrating bug, calling attention to something you’ve found that works well, or proposing some process change. Also a chance to thank particular people or teams for stuff they’ve helped with. Another 30 minutes again with everyone.
And finally the planning meetings. Reviewing what was completed and not completed in the previous sprint, picking out the tickets (from the backlog of work) that we want to do for the next, and then running through them to make sure we have all the details required for each one. Maybe adding some additional tickets for anything that’s missing. Then a quick planning poker estimation of story points, agreeing on an estimate for each amongst the team, followed by comparing the total estimate with the previous sprint to see if it looks roughly in-line or we have tried to pack too much in. Usually 1 hour, developers and product team only.
The developers will also spend a bit of time over the course of a sprint documenting anything they want to do as a ticket and collecting the appropriate requirements. The product team will also file tickets for anything that has to be e.g. delivered to a customer, as well as long-term roadmap items that form the bulk of the work.
That’s basically it. There are no teams of bureaucracy, or micromanagement, or “progress signalling”, or reporting, or piles of useless meetings. Just regularly checking in with each other, and periodically reviewing and adjusting what we are doing.
The goal of any of these systems is to help produce quality work at a steady pace. Take the bits that work and drop the bits that don’t. We have small teams so I’m sure the nature of the process will change over time, but I’ve worked with far larger teams that were pretty much the same.
Honestly, at this point I find it hard to think of a method of development I would prefer.
Mba-speak, translated:
Value prop = You don’t really need this
Data Science = Not a Real Science
I have it more or less working = It’s not working
I got it working = Please don’t ask me about this anymore
Does this make sense? = Are you even listening?
Let’s stop talking about talking about the issue = We’re halfway through this meeting
Please enter a jira estimate = I am or want to be your boss
Quick stand-up = I’m interrupting your flow
Daily stand-up = I’m interrupting your flow every day
PM = Tom Smykowski
Product = Paid Intern
Feature complete = See “I have it more or less working”
Deep dive = I have no intention of pursuing this
In-flight = I enjoy dramatizing the trivial (See “How Can We Land the Plane”)
This is not intended to offend anyone = This probably offends everyone
Yes.
>Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
It is. Management being able to change direction every 1-2 weeks is fantastic for management but can be really bad for burnout.
Every day you have to talk about what you worked on and what you planned to work on like you're toddlers who can't be trusted to do work.
Every two weeks you have agonizing meetings where you're expected to analyze the past weeks, and come up with plans to improve them as a team. This sounds good on paper but after years of it, you mostly want to shoot yourself.
And that's assuming your team doesn't agree to a 1 week sprint, where the total meeting load can be 10% of the time spent working.
And that's at companies that are pretty good at it.
So yes, it's good for software delivery. But for something called agile/scrum, it's awfully process heavy, and it sucks as an engineer.
Each new book tells a different thing.
Scrum = Communism
That said, some of the ideas in it are good, and I think these days people try to intelligently incorporate individual elements of scrum into their own process. In the long run, the influence might be net positive, even though there's a lot of damage to make up for.