I just don't get it why developers like Scrum.
The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Standing around a table in the morning like assholes is not my idea of fun. Same for the "product owner" concept. If I develop something, I am the owner. I generally hate being micromanaged and being assigned microtasks that gives "them" total control over my workday while I have no idea what "they" are doing the whole day.
Scrum was the reason why I left my last company and I'm much happier now in my new company, where we do not have any process at all, just a common goal. Instead of standups, the team gathers for a coffee in the morning. If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines.
So no more Scrum for me. Never.
I have totally opposite experience from what you wrote.
We have fast changing application and we use scrum and sprints to fend off business people. Because one day they want one thing, next day 10 things more.
With sprint I can tell them to go away and make priorities because team is not capable of handling those 10 more tasks. Which in turn makes it predictable for business people because they know my team will be able to put those 10 things in next sprint (if those are soooo important, which later always turns out not really) and have it ready in production in 4-6 weeks.
With product owner and "refinement meetings" I don't have business/sales people coming to me with stupid ideas and trying to force me to implement something. They have to put more work in it so that I get structured stream of work, of course it is not always perfect but better than random sales hitting you with something by your desk.
What is important I have my team "burn down rate" which helps to communicate it clearly and they cannot argue with the number.
Other important part is that estimations are done by dev team and I think important part is that our management is not arguing with the estimations. They show trust in developers and are not trying to push down estimations or improve burn down.
So in my view my team has more power over the process not the managers. What managers/sales get form it is clear information that they can use in their work. Unfortunately I don't think it is the case for much companies.
I mean I get the problems you're facing, but is there anything about scrum specifically that makes it easier to deal with them?
We just have a list of tasks we need to work on organised by priority and a quick estimate of the time needed to implement it. We don't need to meet every morning to follow that list, going through the list and re-arranging it once a week is fine.
If someone outside of our team wants to know what we're doing, they can look it up. And they trust us that we know how to prioritise tasks related to our own product.
I've worked within a scrum team before this and I prefer this approach so much more. Prior to this I never knew what I would face that day. It's whatever the project manager told me I should face in the morning meeting, even if it meant setting aside something I didn't quite finish yesterday but could finish within an additional hour or two.
You found a loose "lowercase A"/kanban approach that works well for your team! I also kind of prefer a kanban approach, if it works well for the test of the team/company.
> It's whatever the project manager told me I should face in the morning meeting
Just to be really clear - this is not "scrum". People can have a really difficult time with "agile" and related practices because they're often conflated with bad people/managers/teams. For most of my developmement career I've followed some sort of agile-two-week-sprint-scrum-with-daily-standup process and I've never been told what tasks I'm doing each morning. I've never experienced this problem you started (but ive definitely had other problems!)
At the risk of being a bit no true Scottsman, the best agile practicioners (and I don't mean the Deloitte/Thoughtworks paid-by-the-buzzword type) advocate for finding a process that works well for your team, picking bits from the larger "Agile Toolbox". That's True Agile.
We’re constantly refining our processes. It’s like any other part of the business in that it benefits in having a design thinking methodology applied or else it goes stale and fails to keep up with changing dynamics of the business and beyond. For example we decided to do fewer releases against conventional wisdom because we realised our customers were not able to keep up with training and other internal processes they are required to conduct for compliance reasons.
Exactly. When I first learned about Agile development they clearly stated there is no "Agile process". It is simply having only the minimum amount of actual documented/enforced practices needed to ensure smooth development. Is your team struggling to finish tasks because they're not communicating enough? Have a morning check-in where anyone who is having an issue can state their issue, someone else can chime in that they can/know how to assist, and they can discuss it afterwards. Team being overwhelmed by requests for new/unplanned work? Set up a task tracking system and prioritize your tasks ensuring things get done in the order they need to be with none forgotten. Software development doesn't look the same anywhere you go. What works for one team/customer/environment won't necessarily work for any other. Agile is adapting the process to the people. Alternatives like CMMI do the opposite by forcing the people to adapt to the process.
The number one issue I've encountered in my area is companies that say they use Scrumm when they really don't. Scrumm is a very specific, defined process, and as they clearly state in their "handbook" if you're not following the process exactly as it's described then you aren't doing Scrumm. Period.
I agree with this.. I've personally been more effective in an async communication type of approach. Communication over email, slack messages, ticket comments.. just leave a comment on my ticket, give me time to ponder on it, then I'll respond. If there's anything mission critical that really requires everyone to sit down in a room together, then we can schedule a meeting.
I think your preferred way of working is pretty close to what scrum aims to achieve. Often scrum gets implemented in totally the wrong way so I can understand your negative experience.
The scrum guide is treated as a holy text by some, but (as the scrum guide even states) agile teams should be self-organising and pick and choose what tools work for them.
> We have fast changing application and we use scrum and sprints to fend off business people. Because one day they want one thing, next day 10 things more.
Then you are using Scrum to obfuscate a core communications problem in your company. Either the business people are clueless about what they want and are flailing around in a panic, or they are not able to communicate their needs to you properly, or you are unable to understand their real business requirements, or they insist on micromanaging every aspect of your product. Or some combination of these factors.
You should not have to "fend off" your professional colleagues, you should be able to have an adult conversation with your peers and frame requirements and expectations accordingly. If your company culture prevents this then that's what you need to fix, not further burden the team with the demands of Scrum.
It's nice of you to write that and you aren't even wrong but what is he supposed to do about it? File a case to have the business people fired?
You're phrasing it as if OP is the problem but he isn't, at least not the most significant part about it. Have you ever been in an enterprise environment where people simply and subtly tell you to fuck off if you want to "have an adult conversation with your peers"?
Now you're stuck with the shitty situation and need to start fending idiots off because there is often ZERO interest to improve things like communication. It's often not a startup with 10 people where you can grab a coffee and go "Hey guys let's talk about our communication issues!".
These topics are highly political once a company is large enough and they are extremely rigid and hierarchical. Exceptions exist but they are, well, exceptions.
Sorry, but I felt this post was almost accusing OP of inaction when that's a pretty easy thing to say from the outside.
Communication overheard is an inherit trait of large organizations. To some degree we can improve this with digital technology, but it’s a fundamental problem.
If you need to rewire the communication pathways of 10 people, the complexity can be up to O(n^2) because you might need to make adjustments for how every individual is getting signal from other individuals. As organizations grow the old pathways of communication are less optimal, but it’s also more expensive to rewire communication. To some degree corporate communication overhead buys stability and consistency across the organization.
You should attempt to optimize communication with those nearest to you in a large workforce, but at a certain point all you can do is give feedback to corporate about the communication pain points. If you work in a large organization and you can optimize your local communications to be completely optimal you probably aren’t communicating with enough people to have a full impact on the organization.
I'm not accusing the OP of inaction: on the contrary, they are attempting to rectify the problem with Scrum, so they are trying to do something.
What I am saying is that using Scrum to paper over a dysfunctional organization merely adds more dysfunction. It's a bit like the old joke: you have a problem, you adopt XML as the solution, now you have two problems. If you have a dysfunctional organization, then you either fix that if it's in your power, grin and bear it if you can't, or leave if that's an option. You're not going to fix it with Scrum (or for that matter, Kanban or any other off-the-shelf process).
You’re offering criticisms of what OP is trying to do, but you have not offered an alternative. What is your solution?
Thus far, your position on this is too rigid and does not account for the spectrum of: org size, type, age, etc. It lacks maturity and awareness of the realities of many organizations.
If you’ve found a place where you can implement this stance: great! The vast majority of people are not in that position, and criticizing them for it is not a great look.
No, this is obviously not what I said. Nor is changing employers automatically better. There are (as I suspect you already know) a myriad of factors involved in choosing an employer and choosing to leave.
The implication that this is “the solution” is pretty naive.
Then you are using Scrum to obfuscate a core communications problem in your company.
No, they're using scrum to guarantee a minimum level of effective communication. Business people don't have to be "clueless" to be constantly shifting priorities: they are reacting to the day-to-day business realities of client requests and biz dev opportunities. They're acting professionally, and in good faith. But if the dev team constantly reacted to those shifting priorities, the constant context shifting would kill their productivity and morale. Scrum provides a minimal set of tools and practices to ensure stability for the dev team, so they aren't constantly in reaction mode and have space to think about the product and be proactive.
I'm constantly amazed by people who talk about the "burdens" of scrum, like it's a lot of work that wouldn't otherwise happen. Really? Let's look at all that "extra" work:
- talking to your teammates daily to share progress, but more importantly raise red flags if there are impediments
- demo-ing your work periodically to verify that the stuff the team says is done actually meets expectations
- periodically taking some time to design the software, maybe refactor stuff that isn't correctly modeled, and planning your work
And that's pretty much it. Do people really work in places where they don't do any of that stuff? They just wing it, test everything at the end, and hope for the best?
> Business people don't have to be "clueless" to be constantly shifting priorities: they are reacting to the day-to-day business realities of client requests and biz dev opportunities.
That makes the business people sound a lot like the guy in Office Space who takes the specs to the engineers. If they are just a secretary who will rapidly oscillate priorities based on what customer yelled the loudest yesterday that isn't very useful to the business. The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.
> If they are just a secretary who will rapidly oscillate priorities based on what customer yelled the loudest yesterday that isn't very useful to the business
This is a gross mischaracterization, and depends greatly on the industry, stage of the product, nature of the customer, etc. I've seen major organizations shift an entire 6-12 months of roadmap to cater to one or two key customers with unique requirements, just based on the sheer size of the revenue from the deal.
Re-prioritization happens for many reasons, and while it's absolutely true that rapidly shifting priorities can be a major red flag and may be extremely detrimental, it's also true that sometimes this is just the nature of the beast. And when that's the case, having a good business/product/whatever you label it layer to shield the engineering teams is critical.
> The purpose of a product team or anyone in that capacity is to try and understand client needs prior to the client actually having them, rapidly changing priorities is generally evidence of that not happening.
Again, this depends on the kind of software shop this is. If you're building the next social media platform, you have an entirely different set of problems and concerns from a behemoth enterprise software platform trying to beat the other behemoth for that next $30M deal.
Agreed. Most of the complaints I read that aren’t just related to awful management are typically to the effect of “I’m being required to function as part of a larger organization instead of doing what I want.”
There are no perfect solutions to project management, and if you prefer to work in tiny organized communes without corporate direction then that is your prerogative. I’ll be right there with you. Otherwise, it sounds like some developers here are just annoyed that their team and departments don’t revolve around their individual desire to not be managed.
Totally - you shouldn’t. But sometimes you have to use common tools and practices to protect your teams workload and manage the expectations of an often frustrated larger business.
Plus not everyone has the privilege of a good base experience, or the option to just find a better cultured company.
How do you solve it when you have Billy and Bob.
Billy is working on customers X, Y, Z.
Bob is working on customers C, F, G.
Billy and Bob want different things for different customers.
Billie gets commission on solving stuff for his customers, Bob for his own.
Both of them promise their customers everything next month.
Now you have 10 developers and Billie convinced 5 of them that building his things is important.
Other 5 devs are convinced by Bob to work on his ideas.
Developers are not informed about how much each customer is worth, as they don't need it for their jobs (just as Billie and Bob don't have any access to source code, databases and servers). Remember you need to have "least knowledge/privilige" principle because you don't inform all employees on all details of company deals (because I am writing about B2B products).
For me professional way is to have a product owner who listens to both of them, knows how much each customer is worth for the company, checks with the team how much each feature costs and makes priorities. You create a single line of communication and defined process. You communicate in a clear way what can be achieved when, well maybe with a bit of a slip here and there. Billie and Bob get one person to communicate with, get clear forecasts that then they can communicate back to the customers.
Maybe that is different if you have B2C products because then you don't have such scenario there.
My last place had those problems, but scrum was used in the opposite way. If we pushed back on things, we weren't "agile". Burn down was used a a club even though the model they chose would usually result in everything pending until the last two days of the sprint. Our estimations were completely ignored, plus the fact that they were estimations. We would make estimates, and be told they weren't commitments. Later when stuff would be pulled into the sprint, the team lead and manager would lower them, and we'd be castigated for not meeting them.
> We would make estimates, and be told they weren't commitments.
Yeah, this is ridiculous; Scrum actually changed the term from ‘Commitment’ to ‘Forecast’ back in 2011. But the industry didn’t pay attention to that minor but important change.
It seems like your team is at war within your own company. You are actually building a wall! That doesn't feel right, and doesn't feel any more positive than what the previous comment was describing.
It's not a wall, more like a moat with a drawbridge :)
The drawbridge is lowered every two weeks and that's when the team delivers and demonstrates the stuff they did during that time. This is also the time the stakeholders get to present the prioritised list of work that needs to be done during the next two weeks (Product backlog).
During the two week period if the stakeholders need to communicate to the Fort of Scrum, they can shout from the other side of the moat and the Scrum Master is the only one with access to the only tower in the castle where the shouting can be heard. The team has complete autonomy and peace to work for the two weeks.
And here I am, building tunnel under the moat, being cozy with the stakeholder in order to influence his decision and secure some sprints that make sense ( for my team, I absolutely don’t care about the product, it’s a lost cause behemoth, the product will be fine. )
I don't think so. Within a company departments can have different interests that sometimes clash. A mature team would notice this tension and signal this to the stakeholders. I think developers often think that people outside scrum teams have a well thought through plan of things they are doing. That's often not the case, they're just trying to figure out what they need to do to get things done. If a team signals that business people need to make a priority call, that brings a lot of clarity. I think it's a good sign.
But this is exactly why we have these processes! Companies have trouble prioritising and planning _at scale_ - they're constantly at war with themselves - so we introduce a process to manage the inefficiencies of many people, with conflicting priorities and points of view, trying to develop a product.
I don't see it as a wall, but defined order (how new tasks are put into the queue) instead of chaos (when sales people come directly to the developer's desk and order new requests without others involved)...
I propose that you read "The Phoenix Project (A Novel About IT, DevOps, and Helping Your Business Win)".
I don't feel like I am building a wall, I am building a structured approach to communication and software building that is predictable to deliver value to our business and our customers.
Well, I enjoy talking to the front line aka sales people to hear what's going on out there. I appreciate their input. While there might be lots of stupid ideas, there are also good ones, and some times I feel like it is a reality check which helps to get out of the developer bubble.
Yes, until one of the 10 tasks flips one of the assumptions and changes a large scale decisioning system on its head...The processes work for certain type of projects. F-16 pilots have different concerns than 737 jets than a tractor trailer driver than a bicyclist, if moving from point A to point B is what matters..
Funnily enough, it's precisely this attitude which has led to the creation of the product owner role, and Scrum in general.
Most developers I know are emphatically NOT good product people (despite what they may think).
A good product owner is quite difficult to find, as they need to combine:
i) a user-centric view of what the product needs to be,
ii) a business-centric view of what needs to be released, and when,
iii) a developer-centric view to make the 'best' product, from a programming perspective, and looking towards the long-term.
> That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines
This is all well and good until a competitor launches before you (with an inferior product), takes all your market share, and when you eventually launch you're having to play catch-up trying to steal clients. Meanwhile the competitor is reinvesting their initial revenue in making their product better to match yours, which means they keep their clients, keep getting revenue, investment etc.
You may have a better product, but you'll end up going bust.
+1 to your third point especially. I'll even add that Agile development can be a big bonus in any market that has the potential for rapidly changing needs. Even if you don't lose out to your faster competition you may still end up releasing to a market that's no longer looking for the solution that you "perfected". Agile development allowing you to release a functional product as soon as possible, and adding to it as resources allow means you can pivot your development to meet new demands instead of bogging yourself down trying to produce the perfect solution to a problem that continues to evolve.
I found this really depends how "scrum" is implemented. Personally as a developer I like several features of scrum:
- regular retrospectives, for improving the process
- regular demos, for having a continuous process showing value and that we are aligned with the companies goals (anybody who thinks the development team have done nothing for the last x months can simply be pointed to the demo recordings page on the intranet)
- some kind of short regular meeting throughout the sprint to update the PO ("daily standup", but does not necessarily need to be daily, or standing up), who can reset expectations, as opposed to announcing at the last minute it won't be ready.
- and a regular planning session with the product owner to work with them to figure out how to bring value to the business quicker, push back on things that aren't that valuable, etc.
But of course this really depends on how the process is implemented and the environment you're in. If retrospectives and demos are often cancelled because "we need to ship this feature to this customer now!", if the daily standups become all about "why is this not done yet, how much longer will it take" rather than an honest peer-to-peer "are we on track for delivering this, what does the PO need to find out/inform stakeholders of/what blockers are there" and the PO doesn't include development staff in the backlog refinement and just dumps tasks on the development team, then yes, you will have an experience that sucks.
So as a developer, I like doing scrum when it is implemented in a way that the dev team and PO are viewed as peers and we don't skip any of the meetings. And I hate doing scrum when it's essentially just being given a load of tasks that I have no say over, no retrospective to improve things, etc.
YMMV (depending greatly on the setup/environment you are working in, I think)
Scrum can only be successful if everyone is viewed and respected as peers. This is a hard requirement for scrum to be scrum. Otherwise it's just micro management.
Often neglected are the Scrum values: Commitment, Courage, Focus, Openness, and Respect. Values form a foundation for success. When agile principles are ignored and Scrum values not incorporated, Scrum (or any other methodology or set of practices) can become just a control mechanism for Taylor-istic "resource management." Scrum can be a great way for a software engineering team to and operate when they understand and apply the values and use it to self-organize, deliver regular increments of valuable software, inspect and adapt.
Every time this topic comes up on HN it devolves into "if you think it's bad you are not doing it correctly". Perhaps everyone is indeed doing it wrong, but when 90+% of the intended audience is "doing it wrong" it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
> it might also be the case that the system is either too difficult too learn for most teams or the system does not match the incentives imposed by the environment it is typically deployed into.
The system is simple; the implementation is often shallow and ritualistic, imitating the how without understanding the why. But the way that the question was asked leaves a lot of room for interpretation. I think it is important to consider a technique as it was intended vs as it is implemented. It would be the same for TDD, or pair programming, or object-oriented design patterns, and so on.
When implemented properly, scrum is beneficial, because it makes it easier for the information to flow through the team and for the team to adjust to the reality. When implemented poorly, it is a hurdle, because it degenerates into a bunch of pointless rituals.
The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too. What would be really interesting is a scrum variety that is easy for people to follow without losing effectiveness.
> The "system" for dieting is also simple (eat less, sport more), and yet many people struggle with that too.
Yes, but do people then go around saying "this dieting thing is totally dumb and a complete waste of time", "I just don't get why anyone would go on a diet", etc.? And how do those who have managed to stick to a diet and think they have benefited from it look at such people? Because this is the attitude that I think I am seeing in many comments in this thread.
Scrum is not dieting, it is just a particular diet. Dieting is agile. And it turns out that Scrum, like all faddy diets, only works for a very small percentage of teams, probably due to their particular character.
That character of enjoying being micro-managed as far as I can tell.
> That character of enjoying being micro-managed as far as I can tell.
We still haven't established what is it about scrum that makes you say micromanagement. Do you regard all prescriptive statements as micromanagement? Is a software framework, such as Ruby on Rails, or Laravel, or Django micromanagement? Are code reviews micromanagement? Is version control with git micromanagement?
Which is the point I hoped I had made, In fact when I was young I worked on a project for BS5750 (aka ISO 9000) and the v senior guy at BSI mentioned that very thing to me.
To add onto this: the argument of "you're doing it wrong" would never pass a usability or safety test, but this gets conveniently glossed over whenever the Scrum debate comes. Trying to wave the point away just makes matters worse. If that crowd believes this point is moot, they should actually defend why the 90% doing it wrong doesn't have any significance.
By admitting it is both right and wrong, and it entirely depends on the context and purpose whether one should decide it is "right" or whether it is "wrong".
Kids are using electrical plugs wrong when they stick a pointy object in it. That doesn't mean electrical plugs without child safety close to the ground aren't potential hazards.
Kids damaging their hands doing control-stick spinning minigames using a N64 controller without gloves are "doing it wrong", they could just wear gloves. Still, Nintendo lost that case, and such minigames were deemed problematic.
People browsing a website where the links turn invisible, the mouse doesn't turn into a pointer, the browser doesn't show it is loading and no loading icon is shown, are "doing it wrong" for not just waiting 10 seconds for the page to load. Despite that, UX practices rightly condemn this kind of behavior: at least add an "alive" indicator.
To some degree, you have to make things "stupid proof". That's part of this field. If for some reason, Scrum allows managers more power to micromanage, that's a potential hazard which has to be admitted. That's the problem with the "you're doing it wrong" argument. It doesn't acknowledge potential hazards. Instead, it tries to circumvent that discussion and blindly assumes that developers both can and should "just fix it" when managers are doing it wrong. There's no discussion to be had when everything goes back to "you're using the tool wrong", even if that tool is designed poorly.
What's worse, go and be the guy telling managers that Scrum should be getting them out of a job. The only people I see doing that are the people not dependent on managers, e.g. Uncle Bob and Allen Hobub, and anonymous reactions here. When you're the one who might lose their job making that statement, suddenly, suffering under misimplemented Scrum and whining about it on the internet doesn't seem so weird anymore.
Scrum requires some premises that many businesses have problems adapting to if they've had a micro managed process before.
Scrum is, for better or worse, an all or nothing if it is to reach its full potential. Once you have "real" Scrum, you can start adapting the overall process through retrospective. But if you start your scrum adventure with "Scrum but..." then it's not going to deliver of the promises.
It is not just micromanagement, it is also the rest of the business culture. Ego-less development and placing the team over the individual can great for productivity. These productivity gains accrue to the profit of the wider company and _might_ partially flow back to the team, possibly as a bonus or possibly as promotions. However, effacing yourself for the team is unlikely to result in the kind of visibility needed for career progression and with software salaries being what they are that can mean a difference of hundreds of thousands in income over the years.
In a way, scrum and its team-based mechanics form a kind of prisoners dilemma where the first team member to claim credit will gain much more of the value generated than their peers. These incentives need to be taken into account in any framework based on teams cooperating, because they have the potential to rapidly poison any team where people are jockeying for promotion.
The problem is often not scrum but the organization. Any organization can misuse any framework for micro management. Scrum is only successful when it empowers developers. If scrum doesn't empower you, then do something else or try to figure out what's stopping you from being empowered.
The difference between scrum and agile as I see it is that scrum is proscriptive enough that you can tell it doesn't work.
Agile is vague and handwavey enough that you can never really be sure that you're doing it or not. I think that was by design - a badly written rulebook won't spread as easily as a religion you can project your own hopes and dreams on to.
otherwise known as "I'm not going to let Deloitte dictate the One True Method for building software and instead going to think critically about our own team".
Whether you're "Capital A-Agile" or not - following a bible down to the letter - is so completely irellevent. SCRUM is never the goal, developing software effeciently is. It's a means to an end. If you can think critically about what your team/company needs to do this, then you should.
This reminds me of the only company I've worked in that attempted to adopt scrum. We almost spent more time debating about whether a particular practice was scrum or not than we did actually doing that practice.
Have you read the manifesto? The whole point of agile is to continuously adapt the process to fit your team. Following SCRUM to the letter is exactly the thing you shouldn't do.
I'm sorry, but the basis of scrum is the scrum guide[0], not the agile manifesto. The scrum framework is fairly rigid (three roles, five events, three artifacts), and I do not remember whether it allows for much flexibility (one role instead of three, two events instead of five, two artifacts instead of three, that kind of thing).
> I think that standing up is actually really important!
Alas, it seems many people don't - I think I've only been at one place in the last 10 years who actually cared about keeping standups short and focused. I've been at places where standup was 20 people and took an hour every day.
Mind you, I've been at places where standup was only 5 people and still took 30+ minutes every day...
Yes, this is a known trick and that's why it's used in scrum. Like you say it also helps keep things focused as people pretty much cannot do anything but listen.
A famous example of that trick is the UK's Privy Council: "Customarily the sovereign remains standing at meetings of the Privy Council, so that no other members may sit down, thereby keeping meetings short." [1]
> The whole thing was designed to give non-technical people more power over the ones who spent a lifetime honing their craftmanship. Standing around a table in the morning like assholes is not my idea of fun
The morning standup works great when it's all technical people. Keeps the team up to date with each others' progress and cuts down on "I spent three weeks being stuck" problems. Here's what I'm doing, and what I'm doing next, here's what I need a little help on.
When management get involved and the meeting starts with jira thrown up on the screen, sure, then it's terrible.
> If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult.
Here's the problem with that, not every schedule can take that 3 day lag, and someone has to make a decision about whether the product actually needs that new framework, or if it's going to be good enough without.
Maybe you're great at making those decisions, but I've seen many times when people end up going off down rabbitholes either just chasing something shiny, or through a sense of perfectionism that actually holds back release.
The morning coffee also works great. I really do not understand why there is a need for formalism here.
There is a meeting for what's planned for the week. There are the informal gatherings, like lunch. And if someone is stuck with something, he or she just asks for help. Easy as that.
It helps to give a forum to bring up being stuck, and an opportunity for others to hear it when they're not caught up in the middle of their own stuff.
Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort.
Informal gatherings are not an appropriate venue - if this stuff only comes up then, then lunch gatherings are now work, and they're mandatory.
> Plus some people don't know when to ask for help, or when they're (for instance) duplicating effort.
This is the gist of it. Some people just have this (very sincere) belief that everyone else are clueless idiots and need to be nurtured, protected and helped. This is the spirit of our age, and Scrum in particular is just another manifestation of this belief.
I don't think everyone else is a clueles idiot, but there are a lot of them around.
If you have a small(ish) team of great people you can get a lot done with a very informal process. When you start to grow, or you're not necessarily hiring the best there are, you start to need this stuff.
And you don't always need the self-motivated, highly productive builders. Someone has to make small tweaks, pad out the automated test cases, maintain things, document etc etc.
> In my experience SCRUM delays and systematizes everything and kills creativity. Kind of like the military.
Systematizing everything and killing creativity is an essential part of making software projects less risky for companies. One of the largest risks to many software projects is the "bus factor" risk, where one employee leaving will scupper the entire project because they were the only ones who knew how it worked. If you have large sums of money riding on the success of a project, it makes sense to invest some time in processes that can mitigate the effect of one team member leaving. It's no surprise that these processes mimic the military, armies are entirely built around the idea that anyone can die at any moment without much impact on the mission.
Your basing this on what military / historical experience?
At the sharp end of a military I certainly see SCRUM/RAD/DSDM as analogous to the ww2 German style of pushing tactical decisions down to a lower level rather than rigid command from above ala the French.
Another thing nobody talks about much is that Executives and VP level people love to hire people from the military, because they do exactly what you tell them and rule with an iron fist.
Im sure there are ex-military people who are chill, but ive seen some insane ones running tech verticals in the past.
1) Non-technical people outside do not get the power. On the contrary its the team that gets much more power. The team is in charge of doing the planning, etc. If the team says: "we will deliver in 2 weeks", manager has no power to force them. Unless he says something like: "ok, in that case I do not need it and do this one instead - that will bring more money".
2) You do not have to stand for the daily. Some teams do it so it involves a little bit of exercise. But you can just as well lean or sit with your coffee and casually share your progress. Like a kitchen talk.
3) Product owner does not OWN your code you fool :D You are the owner. Product owner commands the product. So if you implement a message queue thats great, you can be proud. But was it really needed? Does it bring any money, stability, a value in general to the product? That is something that usually you cannot answer, because you are focused on the quality of the code and do not care about the bullshit numbers right? But in case you do, you are aware of the whole situation, the market, all the customers etc. and you engage in that part, then you are super senior team member, you are self-organized and you actually do not need a product owner. That is like endgoal for Scrum. To create such teams (with such great and senior team members).
4) Scrum does not prevents you from rewriting the code until its perfect. Like where did you get that twisted idea? Scrum even says that tech debt (bad code, needs refactoring, etc.) is incredibly dangerous and should be avoided!
Simply put, if you and/or people in your team and around are assholes that push just for the deadlines (and bureocracy) and do not care about the quality, that is completely 100% on you/them, not on Scrum. Scrum tells you NOT to do it and gives you the power to resist people that are trying to force you to do it like that. Scrum encourages you to share the knowledge and work with others to produce better quality and make your day more easier, comfortable without micromanaging, etc.
First of all, I'm not making the decision by myself, but discuss it with my peers before doing so.
Second of all, the product owner does not command the product. We all do. At least that's how we see it here and it works out quite well. And we are not wasting time on childish stuff like giving story points to our micro tasks or sprint retros.
And of course we care about the business numbers. Or do you think developers are too stupid to realize that this is what counts in the end?
Everything you said is great, but it's not how it plays out for a lot of developers. The people and the politics don't go away because some rules have nominally been adopted. Politically adept people¹ in manager/PO roles will continue to pretend they're following the rules while doing whatever they damn well please.
And when what they please is to micromanage or worse, the developers haven't suddenly gained people savvy because of these rules. They will have just as much trouble fending off the problems as before. Possibly more, in fact, because the (Scrum) rules can be used as cover. Or lead the developers to believe they're protected by the rules, so they don't need to be aware of politics.
---
¹"Sociopaths" if you will, but in the "Gervais Principle" meaning, not the DSM.
I came from the company that virtually invented Scrum (Easel Corp / Jeff Sutherland) -- showing my age now, I assure you -- it wasn't invented to give non-technical people the power over developers. In fact, it was quite the opposite. It was created to help developers ensure that their lives could be validated in the timebox of work that was required of them. No offense, but you need to probably work in a better Scrum environment. Sounds like you haven't experienced Scrum properly.
as soon as he went all "the managers", i knew he'd been poorly educated around Scrum. The funny think about Scrum is that upper management doesn't like it. They'd rather operate in a waterfall approach because they can blow up roadmaps and not have any trace of the offense. With Scrum, you can do the "Ok, but that will require you remove X points from this Sprint and replace that work." Which has a check and balance on that sort of problem when someone wants something unplanned or changes scope on things. Scrum's s a tool to ensure that you have some level of "management" for the management but also it demonstrates how developers aren't always magicians. That's what people who don't like Agile/Scrum don't quite get.
I don't want to be "that guy" but everything you're describing above is not a symptom of Scrum per se but of a toxic working culture. Scrum does not suggest micromanagement or assigning tasks, the goal is for the team to be given a goal and work out what is needed to be done to achieve it. The team works together, no passing back and forth.
As for the PO being a "they" that's something that needs to be addressed. I'm not going to assume ill intent on your part, so let's assume this is again a symptom of a poorly performing team rather than you (or the PO) being unreasonable. But also bear in mind that the PO going off doing "stuff" is generally supposed to be all those things that get in the way of development, e.g. talking to stakeholders & customers, addressing prioritisation problems and trying to prevent the team being overwhelmed with too many goals at the same time.
I'm definitely not saying that micromanagement doesn't happen but I'm saying that you could take your new company's approach (no processes, just let the devs do anything) to the old company and you would have many more problems. It all, as ever, boils down to working culture and practices, and a company that is agile in name only. You can't fix that by splitting things into 2 week chunks and making people talk to each other once a day.
We do have a process. But it's less formal. Weekly meetings, priority lists, technical discussions, business discussions. If a problem comes up, we just talk to each other. It's easy and makes for a pleasant environment.
One thing I've learned over a long career in software is that a "bad" process that is followed precisely with top to bottom buy-in will always out perform the "best" process with lots of exceptions and lukewarm buy-in.
If you want something like Scrum or agile to work, you must have technical project managers that are independent and, quite frankly, they need to be assholes holding both the tech side and the business side equally accountable.
I see what you mean, and perhaps many/most standups feel pedantic.
But more generally, even in the total absence of "managers" and non-techies, communication is a good thing? Teams not individuals create great projects. Adhoc comms are great, but catching up with other technical folk casually over coffee daily for a couple mins (not more!) seems like a good idea?
Perhaps it's more the pedantic _format_ or feel of most standups that are what's terrible?
Teams are supposed to be self-organising in Agile.
When you implement an anti-agile process such as SCRUM and don't let the developers choose how to communicate, then no, it's not true that more communication is better.
Scrum is only anti agile if you read the guide and think it must be done exactly by the book.
Scrum dictate Planning, Review, Daily and Retrospective. How you do planning, review daily and retrospective is fluid and often adapted during retrospective. When you start you do it by the book and morph it into what suits the team and organization best.
> And yet here you are talking about processes and tools
First, the Agile Manifesto is not rejecting "the items on the right". It recognizes their value.
Second, the four principles of the Agile Manifesto are extremely general. It does not offer any recommendations on how to achieve the "items on the left". Scrum has a set of concrete recommendations for doing that.
Third, scrum respects all the "items on the left" of the Agile Manifesto. It emphasizes the importance of "individuals and interactions", of "working software", of "customer collaboration", and of "responding to change", and offers a framework for achieving them.
First, you're focusing on the very things it says not to.
Second, you're focusing on the very things it says not to.
Third, you're focusing on the very things it says not to.
You can't win this, Scrum is usually a proscribed process from management forced onto teams.
That's, by very definition, is the antithesis of agile. Agile is supposed to be about self-organising teams that decide how they work best. If that's scrum, fine, but if that's imposed by management, it's not agile, it's anti-agile. SCRUM, SCRUM masters, SCRUM cards, etc., etc. etc. are all anti-agile by very definition.
> If that's scrum, fine, but if that's imposed by management, it's not agile, it's anti-agile. SCRUM, SCRUM masters, SCRUM cards, etc., etc. etc. are all anti-agile by very definition.
There's a lapse of logic that is happening somewhere in the middle of this passage.
You can say that self-organising teams can decide that they work quite well within the scrum framework. Good.
You can say that self-organising teams can also decide that they do not like the formalisms of the scrum framework, and prefer some other set of guiding principles to achieve their agile ideals. Good.
You can also say that the management may muscle their incompetent way in and impose scrum upon the unwilling team, and by doing so divorce scrum from the agile principles that it was intended to uphold. Fine.
But what you cannot do is to conclude from the last statement that scrum is anti-agile. Just as you wouldn't conclude — if the management were so insane as to demand that all their teams program only in ruby — that ruby is an anti-agile programming language. What happened in that last statement has nothing to do with scrum and is no fault of scrum.
I don't like Agile when it's sold as such. I absolutely refuse to discuss Agile with certificate peddlers. SAFe is the worst of the bunch, with expiring certificates, they make money on renewal.
I'm a developer now managing product. if you apply a historical analysis perspective, Agile has either influenced our process, or our process may be described as post-Agile.
We have a backlog, organized by priority. We have self-organizing teams. Teams make their own planning and own their backlog. I, as the person responsible for product, take time meeting the people involved in making the product work in the market. Such as legal, finance, etc etc. The team does not have to participate in this, but they are welcome to.
What I have fought hard for is to not have management push tech stacks at teams. Developers get to decide, unless there is a legacy situation, and then they get to decide if they want to work with it. And we have a clearly defined org culture. That's as in who gets paid more, promoted, and why.
The developers have a higher-than average salary (algo for market value known to all and published internally), a % set bonus from total net, and an option to go for a higher % of bonuses by forgoing some of their salary. Some people like a known salary, some prefer a chance for a higher pay-out with more risk involved.
I'm writing a master's thesis on project management at the moment, part-time, and have had to do entirely too much reading up on Agile and project management history.
Like I wrote, we can absolutely be classified as Agile. We just don't have it pushed down our throats, and we have a realistic culture - our part of the business is dependent on excellent developers, we treat them with respect, give them decision-making power, offer a share of the profits, and expect them to care about the product as a whole and their part in it.
If the "Agile" you have been exposed to does not treat developers with respect, nor establish a mutually beneficial organizational culture, the market will sort the organization out, as long as developers remain a crucial part of the equation.
I see the Product Owner role the most critical for the success of Scrum in general. This is for PO's simple yet not given properties - vision about the product, vision of success, and the ability to express this.
Everybody else in Scrum is depended on the PO's abilities. One can train to improve the expression and prioritization skills, but it's very hard to train to develop or (even to appropriate) a vision about the product and the success.
This becomes even more acute in corporate environment, most PO are recast from former Project or Product Managers, who by definitions are Managers, not visionaries, nor intended customers of the product.
As a result, that critical element - the product vision - simply cannot be shared. It's just another "Quarterly Goal" in disguise - "the stonk must up!".
So the corpo-Scrum has a greater chance to devolve into shared lack of vision and collaboration theater.
One could paraphrase "Show me your PO, and I will tell what your Scrum is".
I really haven't experienced this sentiment. It sounds like you had a bad experience. Scrum can be amazing depending on who is implementing it. Even 7 years ago at AWS, micromanagement wasn't and couldn't afford to be a thing, yet we were most definitely a Scrum team. It was what held us together despite the lack of management. Yeah there would be arguments between PMs and devs, but that is healthy, and most often the PMs lost said arguments. Everyone was placed adjacent to one another, and I adjacent to the project manager, which gave ample time for arguments, but in a way that was better for the team as a whole. It introduced a sort of democracy with continual meetings to ensure that we were working efficiently at any given time.
Agree completely, for a period of time I was working scrumless and quite happy with it. Got a new manager and some new tech leads join and suddenly we need several stand ups, scrums, and checkins because they don’t know how else to figure out what’s going on. It sucks.
I’ve never witnessed “I’m having trouble on this” -> “Oh I ran into that before, have you seen X” in an official Scrum. Official Scrums are just status updates for your manager/other authority figure.
We’re also cargo culting other processes (sprint planning) that don’t even fit in with how our company does planning - we do everything quarterly, most tasks aren’t really re-assignable - so it’s just a shaming session for people who underestimated task lengths or are running behind.
But, ironically, you are being 'Agile' in this new role.
I mean the term is sooo elastic it is hardly meaningful, but if you have a high skilled team, with clear shared concrete goals, producing code at pace, where the code is the measure of progress then that meets pretty much all the things that got written down in the Manifesto.
The fact that the manifest is just an observation of what we all know - how it feels to do really good work in a team, well, great.
The problem with Agile / work / life is that its hard to get all those pieces together and just as hard to maintain.
I think Programmer Anarchy is closest to the right idea. Get a bunch of (skilled) programmers together and give them a direction. But it is called anarchy to emphasise the idea you cannot have non-programmers in charge, or an organisational hierarchy getting in the way.
Changing that is what derails almost all Agile projects - its why Acqui-hires fail to keep the esprit d'corps, its why startups slowdown as they grow, its why steam engines were great before the factories, its ... humans aren't good at letting emergent order handle their day to day lives.
tl;dr - its not Agile or Scrum. Its us - its the difficulty of organising humans, its the constant fight against entropy, its scale and centralised planning vs letting the market decide.
We should all probably live and work under the Dunbar number, and allow markets to find where value is created.
I see ledgers as enabling that. The supply chain will set us free.
Actually, SCRUM was designed to make software dev teams less dependant on management. The problem you describe arose when consultancies decided that this is something that can be wrapped in a powerpoint lsidedeck and sold as "more results faster" to top management for $$$.
That being said, I do not think from your description you have experienced either SCRUM nor Agile.
Your experience is not about Scrum, but about a poorly implemented management: the process or tools proposed by Scrum (or Agile) is there to help the team, and allow to do, make their magic, not to micro-manage and assign tasks. Your previous team clearly failed at it, or we should say it succeeded at using a trending keyword to make their own agenda.
Your new team example doesn't seem much better to me: even-though the freedom you like is what should be, the lack of process can't work in any reasonable even middle-size team. The process is not about slowing you down or giving power to management: it should be there to help you as a team member keep the vision and target, and sharing. How would you know how to collaborate with others on the team if you don't have any way to know what they are doing or how would you improve your creativity if you don't have any feedback on what you are doing?
I think the goal of scrum is exactly what you are striving for: to only have the end result count. If you can achieve this without a process, that's great. However, that puts a big responsibility on the developer: you need to weigh development effort against business benefits and really try to understand the customer. If you are up for it and capable of it, that's great, then you don't need scrum or any framework. You are then the owner, period. However, in my experience, most developers do not really care about the business side of things. Also there expertise is often not in prioritizing development efforts to maximize business value. So I can completely understand what you are saying, but most developers are not you (in my experience) and they do not naturally own the things they create.
Sounds like zombie scrum. A good scrum team will be self-driven. Micro-management from external sources is an anti-pattern and usually means you have a poor scrum master who doesn't understand that their job is to protect their team.
> in my new company, where we do not have any process at all, just a common goal. Instead of standups, the team gathers for a coffee in the morning. If I want to spend 3 days learning a new framework that might do the product good, nobody cares. The only thing that counts is the endresult. That means we are beating the product into submission until its good, even if it means rewriting the thing three times and missing deadlines. So no more Scrum for me. Never.
I love this. Mind sharing the name of the company?
I think you need to separate Agile from Scrum to be honest.
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.
I've found the retrospectives to be the most valuable part of the scrum ceremonies, taking the time to talk through what could be improved etc.
Stand-ups tend to be too much of a status report to the manager and are more valuable when its the developers talking between themselves and sharing knowledge of their work.
My biggest dislike for Scrum is how managers can use it to turn "agile" into basically a MS Project plan from the estimates.
> are more valuable when its the developers talking between themselves and sharing knowledge of their work
This is the biggest lie of standups. No one gives a shit about standups. Everyone is waiting for their turn and then not listening to others. Let's stop pretending. If they need help, they'll reach out to the expert on 1:1 basis. Way more productive, way more concise, better bonds, privacy and learning experience.
No one waits until standup and be like "Gee.. I should ask this help in front of 8 others and waste everyone's time".
This is completely false for the majority of places I've worked. Plenty of people don't notice how much they've got stuck, or don't know who the right expert is, or feel self-conscious about interrupting them to ask a question. Having a daily scheduled time where all the experts are available and everyone should check whether they're getting bogged down is a big help.
I've experienced the kind of "standup" you describe too, but it usually coincided with not actually following the rules for what a standup is (e.g. not actually standing up) and a bunch of other fake agile.
I've worked in a range of different cultures, and you're exactly right. It's "bad culture", it's people who are oriented towards individual competition rather than collaboration. It's when your SME's tear down others for not finding their specialized knowledge as "obvious". It's where the pervasive attitude is anti-documentation, anti-code comments ("if it was hard to write, it should be hard to read") - It's when members are not attuned to the possibility that others lack context because they're in a narrow role without exposure to what the broader team is doing. But mostly, it's just people being assholes.
Being "stuck" working in a company like that really sucks. You can spend years spinning your wheels just trying to keep up. Working at a company that fosters collaboration and non-judmental attitudes. . . it's like night and day, and you can grow your skills and get out of a narrow role, and look at the big picture.
These are the kinds of things that every engineer needs to learn to look for when you're doing an interview somewhere.
Most developers are introverts, everyone has their own pride, and a lot of the time the difference between a getting stuck because you're missing something and getting stuck because what you're doing is just genuinely hard is not at all obvious - especially when you're in the tunnel-vision of trying to solve the problem and in a workplace where you've deliberately eliminated distractions and interruptions (which is a very good thing on the whole, but comes with its own costs).
How is the best situation for a prideful introvert to have a scheduled meeting every morning where they can make it known to the entire team exactly how stuck they are?
If anything those are the exact traits that make devs prefer 1-on-1 communication.
How else to learn humble, team-oriented, potentially uncomfortable honesty but regular practice?
Psychological safety is the biggest factor in overal team performance and morale. That safety comes from trust, and that trust comes from routine demonstration of vulnerability and support.
Lone wolf rockstars can have their own moments of self-defeat and wheelspinning too. But if they haven’t developed a sense of courage and humility to admit it and bring it to the team, then the whole team is now literally bottlenecked on their ego.
>That safety comes from trust, and that trust comes from routine demonstration of vulnerability and support
That's my intuition about what's wrong with these ceremonies: they look like they are trying to foster those things by enforcing the superficial behaviours seen in good teams, but it is just the effect. A team with trust, close bonded and efficient has "standups" and "retros" in an organic way, because that's the effect of a team that work together.
I always felt these methodologies try to turn it around, as in "let's force the superficial behaviours we see in good teams, so it will make other teams as good". But it doesn't work that way and it ends up being a tool for managers.
> How is the best situation for a prideful introvert to have a scheduled meeting every morning where they can make it known to the entire team exactly how stuck they are?
Because the whole team's doing it, because it creates a space where it's ok to have got stuck, and because the once-a-day schedule sets a clear expectation about how long it's ok to be stuck for without at least considering asking for help.
If you were happy getting yourself unstuck asking for help 1-on-1 you can still do that, and you'll never be stuck when it comes to the standup, so it should be no skin off your nose. The standup is for the sake of the people who would previously be stuck quietly for days at a time.
(though if I'm on the receiving end, I'd prefer to nudge you towards asking in standup or at least in an async way, rather than interrupting my own flow by asking me for help)
Sometimes you spend all day banging your head against the wall and just forget. The stand up gives you space and a reminder to tell other people you’re stuck.
Except this is completely anti thetical to the idea of stand ups which are supposed to be peer to peer as opposed to a more expert to non expert relationship.
What you’re really looking for is office hours.
If you’re self conscious about asking questions, how is it easier to do it in the moment with your entire team also listening in, as opposed to a direct IM, or email if you’re worried about disturbing the busy expert?
And how often do people have questions for experts? More often during the beginning of a project, then there’s a lull, then maybe some more questions as you find things you hadn’t thought of, then another lull, and then more questions towards the end where you are trying to close all the loose ends.
Daily standup requires you take up the expert’s valuable time in equal amounts during all those periods. And you have a bunch of people listening in who have no reason to be in that conversation. (A single 15 minute standup with a team of 8 is straight up 2 hours down the drain. And that does not include any of the context switching costs, or the cost of interrupting someone doing deep work).
Wouldn’t it be much bette to setup a 1 hour meeting on day 1 of the project with the expert (doesn’t stand up add a whole role, scrum master, whose only purpose is to direct people to the correct experts, basically? Well, use them if you don’t know who the expert is...prior to scrum we simply went to our team lead for situations like that). A 30 minute follow up at the end of the week.
Then another 30 minute follow up a week later and a 1 hour meeting a week later close to the end of the project.
That’s 3 hours worth of time from the expert in a span of 3 weeks, but the expert gets to hold forth for those entire 3 hours, without having to waste 12 out of 15 mins listening to useless crap. That’s a straight up 20% saving over the stand ups, gets you a full 3 hours from them, as opposed to 20% of the time, gets their attention in decent chunks of times, where you can have a real discussion, interrupts them 4 times over 15 working days as opposed to 15 times, and only includes those who are directly relevant to the discussion as opposed to everybody.
That's a great point. And here is a real example that happened recently at work. One of my teams needs to create the ability for their low-level code to be able to respond to HTTP requests for command and control. So they have all immediately started trying to figure out how to do this. Except I happen to know that another of my teams already did this exact same thing in another project, packaged it up and published it...and the source code is already sitting there on github waiting to be re-used. There is zero overlap between the two teams (two totally different departments) except for me, so in this case I (as a lowly engineering manager whose coding days are long behind me) am able to solve a problem and save time/wasted effort Now, if we didn't do dailies, of course this would come up at some point but we'd have lost a week of productivity or more.
> stand ups which are supposed to be peer to peer as opposed to a more expert to non expert relationship.
Right - I'm taking the assumption that everyone will have their own area of expertise, and "the expert" for a given issue might be any one of your peers.
> If you’re self conscious about asking questions, how is it easier to do it in the moment with your entire team also listening in, as opposed to a direct IM, or email if you’re worried about disturbing the busy expert?
Because there's a specific time at which you're expected to do it. It's very easy to keep putting off an IM/email, thinking you'll just spend a bit more time trying to figure it out yourself first. And the expert has already been disturbed, so there's no need to feel guilty about interrupting them.
> Wouldn’t it be much bette to setup a 1 hour meeting on day 1 of the project with the expert (doesn’t stand up add a whole role, scrum master, whose only purpose is to direct people to the correct experts, basically? Well, use them if you don’t know who the expert is...prior to scrum we simply went to our team lead for situations like that). A 30 minute follow up at the end of the week.
No, having experienced both approaches. You're so much more productive if you have direct, daily access to the expert. On day 1 you don't know what questions to ask; most of what a programmer spends their time doing is exploring the problem space. If you've got a daily iteration cycle where you ask a couple of questions, try things out, and then come back the next day with some follow ups based on what you've learnt, you get a whole lot more done.
> That’s 3 hours worth of time from the expert in a span of 3 weeks, but the expert gets to hold forth for those entire 3 hours, without having to waste 12 out of 15 mins listening to useless crap. That’s a straight up 20% saving over the stand ups, gets you a full 3 hours from them, as opposed to 20% of the time, gets their attention in decent chunks of times, where you can have a real discussion, interrupts them 4 times over 15 working days as opposed to 15 times, and only includes those who are directly relevant to the discussion as opposed to everybody.
It doesn't end up being "useless crap"; everyone is part of the same team delivering the same product, so it's important to have cross-pollination about what's everyone else is doing.
Of course if someone has particular expertise that warrants holding forth for an hour on the subject, it might be worth scheduling a time for them to do that. But there's definitely no substitute for having everyone available every day, at the same time as the rest of the team.
> It doesn't end up being "useless crap"; everyone is part of the same team delivering the same product, so it's important to have cross-pollination about what's everyone else is doing.
And in the same breath, it is a pipe dream to believe this can be achieved in 15-30 minutes every day. That's part of the controversy behind daily scrum: as a status update tool (which, yes I know, it "isn't supposed to be"), it is too long and there are better methods which can be automated. As a tool to actually share things, it is far too short. In both cases, it is incredibly disruptive and goes against most existing theories on flow and productivity. Planning an hour session later is a mitigation tool, though it is arguably an extremely poor one.
>But there's definitely no substitute for having everyone available every day, at the same time as the rest of the team.
And you know that based on an experiment which has been going on in an extremely informal manner for 20 years? Remote work was deemed "impossible" and "no substitute for real work", but many of us seem to do just fine. Let's not count our chickens before they hatch.
> goes against most existing theories on flow and productivity
There's no contradiction; the whole premise is that those are measuring the wrong thing, that the cost of misalignment and building useless things dominates those concerns. That matches my experience.
> Let's not count our chickens before they hatch.
Look, if you've got some magic way to make things work then great. But an hour at the start, thirty minutes each week, and an hour at the end, is absolutely no substitute for having someone in your daily standup; I've done both (or pretty close to it) and it's night and day.
I partially agree but have found it useful to just air my thoughts briefly as there is not always an obvious expert for every subject
"I am not sure about the best way to proceed..." Or "I think I am going to try X not Y..." Or "I got some weird error I don't understand so I am going to be trying to work that out today..."
Often someone will pipe up and say they've had some experience there or faced same issue before and let's talk after the standup or they have a fix in the pipeline for that so don't worry about it until next Tuesday etc etc.
I guess if your colleagues don't listen in meetings though you have a different problem.
I personally find that standups that focus on the outstanding tickets help me to focus on actually working on the tickets themselves :) rather than getting distracted onnbusy work or investigating some curious bug or refactoring something if I have to standup the next day and say "I did nothing on those tickets assigned to me".
You're looking at this from the long angle. Of course you shouldn't wait.
However, many people, without explicit prompting, will in fact never ask these types of questions at all. That is the value of the daily stand-up: it ensures that everyone is prompted to as these things AT LEAST once every day, rather than holding onto them for who knows how long.
I'd also note that, without dailys, it's rather rare to have the entire team together in the same room, especially now with Covid. Ideally you'd ask this type of thing on email or slack, but lots of people just don't bother unless you give them this explicit time for it.
Possibly yes, though I don't know of one which isn't more draconic (e.g. end of day reports) or manipulative (e.g. forcing the team to have coffee/lunch together every day). My point was that dailys are a real solution to a real problem, not that they are utterly indispensable and irreplaceable.
I don't see how a stand up helps. If a person doesn't have the good sense to ask on Slack/room 'Hey, does anyone know how to render a Bezier Curve in OpenGL' (or whatever) and needs to wait 24 hours to do it in a group setting, then it is a problem of communication with that person/team. Now because some people have this problem, the rest of the team has to be interrupted, do a little song and dance ritual and waste their time (and probably lose focus on what they were doing).
I'm sorry, I just can't see it. If people don't bother to do what they are paid to do, then have a chat with them/fire them in the worst case and let the people that act professional and grown ups work in peace.
Firing someone for not asking enough questions seems extreme.
The way I've seen this happen is that someone is assigned a task to render Bezier Curves in OpenGL, they work on it for a few days stumbling through, and 5 days later when they are done with the task that was assigned to them, they try to commit and find out that someone else had been given a task to remove all curves from the display and replace them with octogon segments or whatever.
With a daily scrum, they would say "I'm working on the Bezier Curves feature today" and someone else would be able to quickly tell them there's a problem with that.
In some teams, this kind of communication happens naturally all the time, but in others, people get focused on their own tasks and avoid it, either not paying attention to group chatter or simply not sending out wild questions. 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early. With any luck, a tight knit team would anyway spend that long on coffee together every day, so the daily just formalizes some informal process which already existed - no extra cost.
I didn't mean to suggest firing them if they don't ask questions per se. But lets imagine there is no daily scrum for whatever reason, people are working on their own things, if they don't ask for help and get stuck for 5 days in something without saying a word, I would have a chat with the person asap. If this continued, then yes, probably fire them as they aren't working.
And with the octagon example, there should be some kind of ticket for Bezier Curves and Octogons, if they cancel each other out, who in the hell created those tickets/decided on them? And again, you don't need a daily stand up to have an idea of who is working on what. The ticket board/tracker should give you a good idea if someone is doing Bezier Curves and you pick Octogons.
> 15-30 minutes of lost focus for everyone everyday is really not that big a cost to pay to ensure this happens early.
The problem it isn't 15-30 minutes. It is much more, because unless you are managing with strict work hours, and can make sure the stand up isn't delayed or interrupts someone's work, you are losing a lot more of the developers time. Context and focus is lost if you were in the middle of a task. Time is lost getting back to the place where you were, etc.
It may help with 'bad teams', but if the punishment for good teams is to do that because of the others, then I am sorry, I'm out. Makes no sense.
If it works for you and your team, more power to you. But not for me. (And I would really advise folks to try and understand if the team actually feels stand ups (or any other thing really) are a positive for the people involved, or they are just to 'scared' to raise concerns to not be that guy, as I have seen this happen a lot, going with the flow, but the moment they can speak freely, raise all concerns)
The entire idea of "standups" is one most people get wrong about scrum. There is no such concept as a standup in scrum, but rather, it's called the Daily Scrum: https://scrumguides.org/scrum-guide.html#daily-scrum
> The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is not a status meeting, nor a place to ask the "3 questions", it's a planning meeting, plain and simple. You don't have to walk the board and not everyone needs to take a turn saying what they're up to. It's a communication tool that provides an opportunity to inspect and adapt. The structure of it is totally up to the team.
Seems overkill since plan is to execute the plan we discussed in the sprint. So, why do we need to remind everyone daily that we're just following the plan?
If I am blocked, I don't need the rest of the team. I will fire an email or document and tag people on Github that its blocked.
Also, why are emails not a thing anymore? Email is amazing. Apparently, its old fashioned now. Whatever is happening in tech companies, we need to stop and evaluate what the hell are we doing. It would be a great experiment (I think Gumroad is doing it? I don't remember) where there are no meetings, no slack, and only email, adhoc 1:1s.
I feel like we're not talking about the elephant in the room here and finding ways to justify stand ups or scrum or whatever.
> Seems overkill since plan is to execute the plan we discussed in the sprint. So, why do we need to remind everyone daily that we're just following the plan?
It's the question whether we can adjust "things" to be able to reach the sprint goal. It's the goal that counts, not the way imho.
> Also, why are emails not a thing anymore?
Emails have their Pro's & Con's - I prefer them, but not everyone is able to be precise and on-point in written language. Also, you need to be able to express your feelings in written language. That's one of the reasons I use emojis even in emails. The ascii-ones, but still...
> I feel like we're not talking about the elephant in the room here and finding ways to justify stand ups or scrum or whatever.
Well, I can see the elephant. But people have different opinions on this topic - something you need to accept.
> Emails have their Pro's & Con's - I prefer them, but not everyone is able to be precise and on-point in written language. Also, you need to be able to express your feelings in written language.
This is exactly the opposite of what professionals do. They should be able to write well. It is not optional, it is an expectation. Feelings should not be part of a technical discussion.
In a few years, we're gonna get emojis in an RFC. Just wait, you!
Interesting paper. I guess the biggest problem here lies in the fact that there can only be so much truth seeking. So, with more time and effort, we could come to a conclusion that suits both. But... I don't have that time, to be honest. ;)
The “3 questions” are alluded to in the text you linked (emphasis mine):
>The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
> Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
While I agree with your point that the format is flexible, asking the questions is a good way to keep people on topic.
For sure, I agree that if your team finds the 3 questions helpful then definitely do it. I was just trying to remind people that they're not mandated. People like to scream about how annoying "standups" are how going around the room asking everyone the 3 questions is a waste of time and for many teams that is probably true, in which case, change the format to something that is useful.
I admit I often don’t pay attention during standup. But I definitely do save non-urgent questions for standup vs. interrupting team members (and myself) from whatever they are working on.
I've been in a team that didn't let people talk in turns, but instead quickly went through all the unfinished tickets and asked if they were still going well. That worked better.
That's where the retrospectives are good again, having that time every 2 or 3 weeks to ask questions like "Are we getting any value from the stand-ups?" Then could try not having stand-ups for a sprint, or indefinitely, and see if they're missed or not. Or try not having the project manager present at them for a sprint.
If a team has a good culture around knowledge sharing etc then quite possibly its not required, while for other teams that short time all together is better than nothing.
The biggest value is not asking for help, it's about synchronizing work.
Hey guys, in order to complete this library upgrade task today i need to do a major refactoring in common.js, so if you all could avoid tasks in this area until tomorrow so we all can avoid nasty merge conflicts it would be great, thanks.
Or hey, looks like this this test case from nightly is failing? Did anyone change something here recently? Who will take a look at it?
If your standups don't sound like this and only becomes a place to report status and excuses for being stuck (asking for help) to your PO or scrum master, then you have a lot to work on. Unfortunately the later version is very common and often hard to get out of.
Let’s say you have a stand up that is developer only and has only 5 developers. Well within the 2 pizza box limit and really how much smaller can a team get.
A standup where developers are sharing what they are working on and people are actually paying attention means that as a developer I have to pay attention to 4 different technical discussions in the span of 15 mins.
The context switching and mental energy required to do that is tremendous especially when you may already be in the midst of working on your own complicated and mentally taxing project.
And this is the best case scenario. Throw in larger teams, throw in non devs, etc and it only gets exponentially more complicated from there.
The whole idea behind daily stand ups is broken.
What you want, at most, is a 1-2 per week regular status update, at the end of the day, when you’re already mentally tired so the time wouldn’t be better spent elsewhere, and good enough team relation building that you can approach each other directly when you need something.
Agile/scrum tries to replace team building with status updates. When in reality, what one needs is team members to get familiar enough with each other so they know that Jack really gets the post lunch slowdown, so after lunch is probably the best time to approach him because he may not be actively working on anything, while Jill likes to sort out all her emails and communications first thing in the morning and then focus on her work in long uninterrupted stretches, so that’s when I should reach out to her for questions/discussions.
And you need to build the ability in your teammates to be able to think about the bigger picture, and decide whether the question they need answered by Jill right now while she is in the middle of her deep work is really urgent and important enough that it warrants breaking her flow or not, or if it can wait till the next day or if it’s short and simple enough, till you guys get lunch together today.
The Big Lie is that team building can be replaced by process. And the Big Lie is pushed (with the best intentions) because team building cannot be packaged and sold as a 3 day workshop (well, it is, but that comes across as inauthentic and doesn’t usually work well, and team retreats have lost the majority of their flavor because honestly I don’t want to get to know the vast majority of my colleagues outside of our work lives). What it comes down to is good leadership to build a strong team culture, and that’s harder to find and develop.
So instead of making the effort and learning to accept that you will have failures where the wrong person is made team leader, or they were made team leader too early and building feedback mechanisms to identify such mistakes and hopefully correct them ASAP, we resort tom3 day workshops that teach agile and that you can replace culture with regular stand up meetings.
> The Big Lie is that team building can be replaced by process.
This! They try to do it backwards: instead of building the team that will organically end up having standups over coffee in the morning, forcing the behaviour in the hopes that will build the team.
> have to pay attention to 4 different technical discussions
Seems like a mistake to have actual technical discussions in a stand-up. So yesterday I've worked on X feature, I've gotten pretty far but I'm being blocked because of a dependency on Y feature. I'd like to continue today, developer Z (who is working on Y feature) can we discuss this after the stand-up? Of course, I could've communicated this before - and maybe I've already done that, but the rest of the team doesn't know. What if they want to pick up a new story that has a dependency as well. Should all this communication just happen in emails or slack messages? That's fine I guess but it doesn't hurt to have 15 minutes to get a good view of what the rest of the team is doing.
Once you get into the nitty gritty you should honestly just say hey let's take a subset of this group and discuss it after. Works for us. Non-dev people shouldn't be there, or at least shouldn't get turns unless they're actually working on issues in the sprint.
I will second retros. I have seen team cohesion go up and down based on the quality of the retros. It is really hard to do a good retro, and ideally no one from management should be present for at least half of it. Making a space where people feel comfortable airing grievances and feel supported can really smooth out a lot of friction. Bonus points when common pain points are made known so tooling and process can be identified to make everyone’s job easier too.
> I will second retros. I have seen team cohesion go up and down based on the quality of the retros.
Could it be the other way? That the quality of the retros went up and down based on the team cohesion? If that's the case (and I believe it is most of the times, in my experience), the retros are just an artifact, not the real mechanism.
There’s a lot to this, bad moral lead to bad retros. But I’ve seen a team with very high cohesion shut down completely when a particularly toxic manager was present in a single retro. It was very illuminating to watch. When no one feels safe to talk in a retro that’s going to bleed into the rest of the interactions at the company. And while the reverse is true too, it can be set up to be slightly assymmetrical. If you can make a safe space for the group somewhere even if it’s only an hour twice a month it can really help alleviate toxicity elsewhere. It’s not a magic bullet, and honestly I don’t know how repeatable what I’ve experienced is. We had a really good facilitator on loan from another team at one point, and I’m not sure we could have kicked off some of our changes without this person.
The biggest improvement we made to our dailies was to break up the traditional three question structure. Nobody really cares about your status from yesterday. Especially since we work together every day and are a self-organizing team that does not need to report to a manager on a daily basis.
Instead we talk about our plans for the day, ask a lot of questions and plan our collaboration and problem solving sessions. These dailies are usually shorter and I feel like I get much more value from them.
The ‘correct form’ for the stand up is tricky, and probably varies on team size. For a small team (e.g. 4 devs) you probably care a lot about what the others are doing as you’ll likely be interacting with it closely (reviewing it, building on it), sometimes larger teams (e.g. 7 devs) then it might never come your way.
I’ve found that people who stick to the classic “what I did yesterday, what I’m doing today, what blockers are there” set tend to provide really short ‘bland’ updates e.g. “I was working on task foo, I’ll be doing more on foo today and possibly starting work on bar, I don’t have any blockers”. If you’re not paying attention you can miss the fact that the same update has been reported for 3 days in a row and actually there is some unexpected complexity and/or a simpler solution has been missed.
For me, the best stand ups give a little more information and can be a trigger for a follow up chat after the standup. “Yesterday I was working on task foo, today I’ll be doing a bit more because I found doing XXX is a little trickier than expected - but I’m still hoping to get onto bar, no blockers - unless my idea for XXX doesn’t work”
I’ve also found this sort of issue made worse on projects where the Project Management have decided that we shall be “Agile” and do scrum. You then end up with a non-technical PM acting as the scrum master and mandated “best practice”. This always stifles any technical discussion as it is ‘noise’ to them, despite being ‘signal’ for technical folk....
Then you've got lucky, last retro I went.... Managers were present, tech lead sucking leaking asses with their wide ears opened, and best devs leaving to better horizons.
I've found the opposite. Retrospectives consist of a bunch of bland statements with any actionable items getting discarded immediately after.
It doesn't help that few people take it seriously. And there's always one or two people that talk out the entire meeting, ruining any chance of it working for the rest.
No offense but it seems like you're part of the problem then. I've also had retrospectives where bland statements were the norm but as a team you should be able to say to each other, alright nice that the teamwork was great but is there anything new?
> any actionable items getting discarded immediately after
Except that, that's bad and honestly I've never experienced it that way. Maybe because I'm vocal and harp on about things if they don't change but yeah. An actionable item either becomes an email (which we will follow up on during the sprint, if nothing happens it comes back next retro) or an issue in a sprint / kanban board.
> And there's always one or two people that talk out the entire meeting
You've got to claim a stage here. Or if it doesn't pertain to you specifically, help teammates who do get snowed under by explicitly asking them.
I'd really not want to work in the environment you're describing, but I think I'd give it a shot to change it before leaving.
Scrum is basically warmed-up Taylorism[1] for the 21st century, couched in buzzwords like "sprints" and "retros". It's an attempt to make software development an industrial process, stripping developers of autonomy and creativity in return for predictability. Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!"), because they like to be "data-driven".
The irony is that one could still have predictability and metrics without Scrum, and they would likely say as much if not more. Instead of expecting your devs to manually participate in rituals, you can use their actual output over a large time frame and extrapolate those.
Admittedly, that is my biggest problem with Scrum. Humans are by default the most volatile factor. While we could minimize its contribution, Scrum instead inflates the importance of the human factor. Example: estimating.
Grooming the back log for priority with just the people who are critical in deciding that priority, is common sense. Almost every methodology recommends this. Yet estimating is a tough sell: at the start, it is largely deemed useless due to inexperience. Yet as experience in estimating furthers, so too do metrics become available which make estimating unnecessary. Worse is when estimating and even re-estimating practices can easily eat entire days worth of productivity (a few hours per person + a high likelihood of hours around that meeting to be less efficient than could-be, loss or lack of flow). This is before we add that estimating has very little empirical evidence behind it (#NoEstimates) and psychological effects make things even more volatile (anchoring effect, Parkinson's Law, etc.)
I can't speak for others, but I went into this field because I want to minimize the human factor in anything mundane or boring, allowing people to maximize their participation in anything fun and exciting. For me, Scrum does the exact opposite.
> The irony is that one could still have predictability and metrics without Scrum
I like to think that it would take a technically competent manager to understand the progress and performance of the developers. OTOH, with Scrum, you can generate numbers, however meaningless, without such prerequisites.
Honestly, while my cynical self would love this to be true, generating basic metrics (numbers of bugs solved, number of features added, average time a developer spends in meetings, etc.) doesn't require a lot of technical competence and already say far more than a vague metric like "velocity" (which, most of the time, is really just speed). Especially if the tool allows one to do this with a few clicks.
More likely is that, if teams were truly "self-managing", the number of management, management-lite and pseudo-management roles should be lowering drastically every year (or at least converting to hybrid roles). Yet I barely if ever see a Scrum adoption result in the majority of managers losing their jobs or changing the type of role they are performing. I also doubt data scientists would appreciate these middle-school tier statistics be called data science.
Why would you say that? There's nothing in the theory of scrum that makes a claim on the autonomy and creativity of developers. On the contrary, if you look in the scrum guide, you will find words like self-management, and independent, and cross-functional.
> Certain managers like it because it generates metrics, even though the metrics are meaningless drivel("we completed 20 story points this sprint!")
Story points do not figure anywhere in the theory of scrum. It is quite a different invention.
The theory (I'd prefer the word "hype") and practice of Scrum are two entirely different things. And of course, if and when it all goes wrong, you're just not doing Scrum right.
> The theory (I'd prefer the word "hype") and practice of Scrum are two entirely different things. And of course, if and when it all goes wrong, you're just not doing Scrum right.
I'm really struggling with this argument.
So if someone reads a text, picks from it things that he likes, throws away things he doesn't like, tries to apply the result in practice, but without success — how come he gets to blame the original concept rather than his own invention? Why call the method derived via picking, choosing and mixing with bits from other texts by the same name as the original text? What makes people think that they are "doing scrum" when they are not?
>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).
Scrum was actually created by two Japanese dudes [0], and was for the manufacturing industry.
Japanese also came up with Kaizen, which Scrum should be about but isn’t, along with Kanban, the process- not the generic term for workflow that some use it as.
While we’re on the topic of Agile, though, it’s best not to forget its eXtreme Programming roots.
XP for me is the core of agile software engineering I can relate to, principle driven rather than process focused a'la Scrum.
For me scrum optimises for a very narrow perspective of software development which did not align well with long term and sustainable software engineering and ownership. If i was far less than generous I'd say scrum is design for children rather than responsible adults.
For success as a leader i should be focusing on building and fostering a team than does not need the self imposed constraints of scrum but are rather conscientious and vested enough to build and deliver what the company needs and the team can maintain.
Scrum, for me, is not for development but for Operations, I don't even like the term scrum but simply WhiteBoard Meeting. Flatten structure, everyone knows what everyone else is doing, chance to mention things on one's mind, perhaps a hiccup from the day or shift before, not hosted by a ScrumMaster just rotate around the team, everyone has a voice, strict visible time limit.
It's super in Operations.. not super in Development.
Sprints make no sense at all. If you can do it you can do it. Stay at it and go on a spectrum of pumping consistent results to once in a blue moon creating something special. Sprint adds nothing to that other than a phrase to use in a conference call to hide ineffective working practices. I have Sprinted on a 35 hour working week, I have also worked normally on a 35 hour working week. Results are similar aside from stress others show where Sprint = Haste, and Haste != Speed or Quality.
Here here. Loved XP, still try to let it influence what I advocate for at my place of employ. XP leans heavy on discipline. It succeeds well when there's an environment of trust towards the team, and the team values discipline as a way of working better together.
Scrum is pretty lightweight. A lot of people add to the core of Scrum and refer to the whole thing as Scrum when that is not accurate. A few uber coders in a garage cranking out their dream idea may not need Scrum. In my experience, it’s most needed in the corporate world where there are tons of development teams being hounded by managers and product owners to constantly cram more and more work into a fixed amount of time left before some arbitrary deadline, and getting management buy-in on Scrum or something similar can actually be a much-needed protection for dev team sanity.
This sums up my thinking. Scrum is a contract between developers and managers, especially non-technical managers.
Developers have always complained about being micromanaged or being given business objectives that don't make sense or about changing requirements or some such. But non-technical managers at the same time typically complain that their developers are prima donnas and that their team produces unpredictable and non-repeatable results.
If you understand KPI's, you understand scrum. Scrum exposes the development process to managers and in theory is supposed to give them a better idea of what the team is doing, what they're having problems with, and what the consequences of their management directives are. If that leads to better management of the team, scrum is a success.
Yes, and Scrum done well can promote a sense of well-being through fulfillment of points and provides rhythmic but varying work for those that like process.
Done poorly it may create a wealth of problems. The cadence may create undue sense of urgency that may lead to unhealthy levels of stress or to depression and desensitization of missing work targets. Nonsense competition may arise due to points and velocities.
But Scrum reinforces all of that; arbitrary deadlines, sprints check; lack of control, product owner the only named role check; process centric, corporate compatibility check.
The achilles heel of Scrum is that it sold out the prescriptive XP practices that enforce sustainable software engineering discipline as well as communication with business concerns in order to sugar coat the fast feedback cycles. Scrum/Kanban feedback is about "doing the right thing". XP feedback is about "doing the thing right". Codebases on projects using Scrum/Kanban without XP technical practices tend to molder and succumb to what I like to call "Scrumrot" within about 18 months. Seen it happen many times.
I worked at a company where the CEO was into Kaizen and brought it up frequently at team meetings. It was otherwise as dysfunctional as any place I've ever worked. It was also my first, and hopefully last, exposure to "full court" Scrum. Both of these are now flags to me that a company is more into process than results, which is sad, because they both came from good places.
That article doesn't even create anything. It's a comparative summary of existing practices in the manufacturing sector. The word "scrum" appears, exactly once, as part of an incoherent rugby metaphor.
Elevating a waffling HBR feature to the status of antecedent decalogue is totally on brand for the clerical formalists that promote Scrum.
In high performance teams, Agile begins where Scrum ends, and as the remarks here extensively demonstrate, awful working environments won't be improved by a bunch of ceremonies.
Are you totally anti process? If not, which process do you find more palatable than scrum? Your comment is eye opening for me because I don’t know that I’d find a job if I decided scrum was a dealbreaker. What kind of projects or companies do you target that don’t have some flavor of scrum?
I’ve always felt scrum adds value for new teams who haven’t worked together or on greenfield projects in a space the team hasn’t worked before. That’s when the standups identity impediments. That’s when retrospectives uncover process or people issues. Once the team hits a stride it’s time for the training wheels to come off and then it’s just a Kanban board.
If you’re looking for a book — shape up — from basecamp goes through how they develop software and it looks great ! I am giving it a try. It’s very agile but not scrum.
I also agree that after a team gels together there’s no need for a lot of the overhead that comes with scrum.
My experience in organizations have always been to continuously shape the process depending on how the team feels about it and not call it scrum
We've been using this since late 2019, and generally been loving it. The concept of things being bets, plus fixed-time variable-scope are amazing, imho.
Not speaking for OP but agile, straight from the manifesto, itself is anti-process, at least in the sense where...
> If not, which process do you find more palatable
Is a cogent question.
Which process do /you/ find productive and helpful? What would you change? What would you emphasize? Process is a tool to serve you and your peers and your stakeholders. Not to pay fealty. Not to choose sides. It can be picked into pieces and rearranged. It can be recalled or reorganized whenever it’s unsuitable.
Exactly. Sorry for the ambiguity in my wording. I meant that the manifesto (like teams that do well adopting/reflecting it) is against proscribed process.
I don't think that's true, it's "people over processes", it doesn't imply a "no processes" stance, just that you shouldn't _force_ a process and you should adapt.
IMO that's what the agile manifesto is about: adapting.
But that's the opposite of my experience with agile and Scrum in the companies, where it is used as an excuse for non tech managers to enforce what they feel works better for them. In terms of control or, in some cases, micromanagement.
I've never had an issue communicating with a team without scrum, even when very new. On the other hand, communication gets worse with scrum, in my experience. Because everyone knows that the meetings are the time to communicate problems, they often delay all communication until the next day. And in some cases the morning meetings drag out to noon because that's when all the communication is going on, when it really just involves 2-3 people.
Individuals and interactions over processes and tools.
If the team likes scrum thats fine but picking scrum vs kanban, or bitbucket vs gitlab vs cvs, those are details a team cam and should be in charge of and revisit whenever they feel like. Because all that matters is working code, and what gets you there is skilled people that communicate well.
Working code is not all that matters, typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable, sooner or later there won’t be any money rolling in to fund developers writing that code. Not every company will have enough ”skilled people that communicate well” for this to be an automatic byproduct of developers doing their thing, especially in larger or immature organizations.
> typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable
the problem is that this assumes that estimates can be accurate, which in some projects may be the case, but in general there are always unexpected problems, things you didn't know you didn't know, etc.
If it happens that a company goes under because they lost all income because there was no deliverability, the problem was the company had the wrong team of engineers. Either too much "isolated geniuses" or too much inexperienced. Sometimes also happens that the management decides the way of doing work without technical involvement. Even companies I've been that decided to rewrite a mature and solid big piece of software, because they "needed to use more strategic technologies". Meaning, the technologies that were the "cool thing to use if you are a cool startup". And they use Agile (so they claim).
It doesn’t assume that estimates are accurate in that they need to approach perfection, but it does assume that good processes and tools can help make them reliable enough to be useful for the business over time (who of course still have to take the remaining uncertainty into account).
There is a reason the agile manifesto starts with the line I quoted. The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability. But if you dont have those individuals interacting well there is no tool or process that can save you.
> The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability.
Here’s where I disagree and would say that a well-functioning process certainly can help with that, albeit not perfectly, of course. And that is by aiding the invididuals involved in interacting well.
When the manifesto came out I thought it was a great idea, as I recall. But now I can't recall what was in it. Something about "people, not popcorn." Or was that The Cathedral and the Bazaar?
You can say we should separate agile from scrum, but scrum basically is agile today (and Kanban!), modulo the odd free thinking, practically self-managed shop. Agile comes in via consultant after a shop declares itself on a "burning platform."
What it's become, IMO, is work about work. I hated it.
The only contact I have with it now is when my manager has to hang up the phone because she has to go to the standup of other managers. (I drive a truck.)
The infamous scrum of scrums. Always makes me laugh. I think all status meetings should be abolished, without exception. Meetings should be for making a decision with all the players present.
Scrums and such meetings are for the benefit of the organizer (boss, ...). Only exception is if someone is blocked but he is bad at expressing it directly to the person responsible.
I've been part of many meetings/scrums where the point was that the manager gets the info of how things are progressing but the meeting itself was net negative for the developers as they lost their flow and some of their time.
In my experience, the teams that do scrum well don’t do scrum by the book. They look at scrum and modify the things they like to work for them and get rid of things they don’t like.
> Agile is at is core just some suggestions for teams to work well together
I don't think that's right. Agile is a way to manage projects as an alternative to waterfall. The 'communication' stuff on top of that might work well with it, but that's all to do with how you run your agile process. Agile itself is just about the order you do stuff.
Imagine that for your project, there 3 'features' that are needed. Each feature needs, designing, implementing and validating (testing it works). You end up with this grid of all the work that needs doing:
F1 F2 F3
Desi
Impl
Vali
In waterfall, you progress through this grid top to bottom. You design all the features, then you implement all the features and then you validate all the features.
In Agile, you progress through the grid left to right. First you work on feature 1, doing design, implementation and validation, and only then do you move on to feature 2, then feature 3.
The reasons for doing this are many and varied. The obvious ones being that in waterfall you don't have anything useful until everything is done, whereas in Agile at least you have F1 fully done a third of the way through. This also means that you can decide that F3 is more important than F2, and then later that F4 which you'd never heard of is needed when F2 isn't (and you can decide this as you go along).
This bare concept of agile is almost always what you want to do, particularly for software projects. The concepts of backlogs, sprints etc. are all the process that has built up to make this work in real life. Approaches such as Scrum have then built on top of that giving a whole lot of extra practices about how teams should work. A lot of that is variable in usefulness and how well it is used. You don't want to get away from the underlying value of the agile process though.
> When [the three of us, along with many others] created the Agile Manifesto in 2001, Kent Beck reiterated his vision to heal the divide between business and development. Kent created the website, and we were stunned when thousands upon thousands people signed this website. So we decided to form an organization – the Agile Alliance. I was the first chairman of this organization. The next chairman was Ken Schwaber. He decided he wanted to do something else. He wanted to make the alliance a revenue making machine…
> Ken came to me some time later, telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance. Lovely thing to happen.
Spot on. Bringing the stakeholder to the squad (just for a daily meeting, for example) is a great Agile insight which doesn't need Scrum at all. I highly recommend it.
I don't have much interview experience so I am wondering how you do this: "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"
Do you abruptly cut the interview short or do you just make a mental note and continue?
I don't get up and leave. Usually in most interviews at the end companies ask if you have any questions. I usually try to understand their processes and ways of working.
Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate. I had a few replies thanking me, most just don't reply and I had one (only one) insulting me and my experience and saying they only interviewed me out of pity as my experience wasn't good enough (I had more years (8) of experience in the tech stack they used than the number of years the company existed!:)) Was from a Who's Hiring thread here actually :)
> Usually after this, I take some time just to 'calm down' and think about it, and I usually shoot them an email saying that I appreciate the time and opportunity, but I don't think it will be a good match and wish them luck finding a better suited candidate.
I LOVE sending letters like this. It's the politest middle finger you can give to a douchey hiring manager or organization.
I think the value of calming down is normally to not send impolite or passive aggressive communications.
I don't have so much experience interacting with recruiters/hiring managers. However, every time I've let some frustration show at work, in the moment I felt vindicated and righteous, only to feel like an ass about 24 hours later. Normally when I feel the need to vocalize a frustration, I try to write down or remember why I'm frustrated, but wait to actually action the communication until I'm calm. Goes a long way to focus on solving problems, without identifying people as the problem.
I'm not the person you're responding to, but just make a mental note and continue. Personally I'd even continue the interview process, I'm a Scrum hater, but an interesting project, a smart team, a big paycheck? You might have to put up with scrum, it's widespread.
Typically you would just make a mental note and continue. Walking out mid interview is considered kind of rude and it's worthwhile in the long run to not be rude if you can avoid it.
I personally wouldn't work at a place that didn't do it. Scrum ceremonies are there to get alignment. If you don't do them, you end up working on the wrong things. If these meetings take up more than 1-2 hours a week, then you're doing it wrong.
If it works for you great. But this 'you are doing it wrong' is at the core of scrum. When scrum doesn't work, is because you are doing it wrong, and never a problem with scrum itself. No true Scotsman and all that.
I have been a professional developer for close to 20 years, 10 more if you count my hobby/learning path as well. All teams I worked that implemented scrum were a hindrance to me and not a benefit. It may work for others and that is fine, but it isn't a silver bullet solution for 100% of the cases.
I feel like various Agile frameworks might be saying “You are doing it wrong” to people using Waterfall for software development. In that case, I would agree. 16 years ago I talked to a project manager who had done PM for a nuclear plant and Waterfall is ok for that, but not usually for software where you learn more from users about what should be done and tweaked as you go along. Perhaps you are just seeing Scrum in places where they are doing Scrum wrong, e.g. adding to it and making it heavy-handed and overbearing.
If you’re on a team of more than a couple people and you have stakeholders feeding requirements to the project, what do you do that’s so different from the simple process of Scrum? It’s just set up to say, hey, we’re going to work on these items for the next week or two, and please don’t constantly come interrupt me in the middle to ask me to fit in a bunch more things than what we agreed to work on in this short time period. Then we’ll show you how it’s working and you can decide what we do next.
> people using Waterfall for software development.
Is anyone really doing Waterfall now? Maybe earlier some industries used a Waterfall like process. But actual descriptions of Waterfall seem to go back 50 years to Royce's paper, Managing the Development of Large Software Systems. That model was explicitly described as bad. I don't fully agree with that paper, but his suggested improvements are more iterative. Personally it seems like now Waterfall is mostly used as a strawman.
> but not usually for software where you learn more from users about what should be done and tweaked as you go along
I agree with that. I wonder if Agile is highly influenced by it's leaders being closely involved with consulting.
"Hindrance to me" is the wrong attitude unless you run the company. Scrum is not for the team to work faster. It's for the teams work to be visible, understood and correctly allocated. I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates and then doing whatever they want.
What a sad and nihilistic view. Experienced devs are smart people. If you communicate the company targets, priorities and deadlines clearly, they will naturally find a way to self-organize to achieve those goals. Devs think it's micromanagement when they feel like they are not trusted to execute the communicated plans, but are instead required to report every hour worked to some slavemaster who might at any moment "allocate" them to a different task.
Not in my experience. In my experience, if you give the devs leeway, they'll come up with some totally overengineered architecture with the latest tech in it (which is great for their CVs) and will spend a lot of the time bikesheding over nonsense (e.g. killing each other PRs because "too functional" or "not functional enough"). The developers don't care about the company goals, but they care about their CVs and personal preferences regarding languages, tooling etc.
Also, if they team does not deliver, at the end of the day it's their manager who gets the blame, not them - so why should they care? Basically, smart devs are repaying the psychopathy of the typical company owners with a 100% selfish behavior of their own. That's the what I've seen in the wild, not the positive scenario you're describing. Perhaps it's "late stage capitalism" in the flesh.
Well I suggest you stop working with colleagues you describe as psychopaths ASAP for the sake of your own mental health. I could never work with a developer who sacrifices the company's / team's business goals for a line in their own CV.
But it's indeed first and foremost the managers failing not recognizing these attributes in their team members, and not working to fix their attitude (which clearly is the underlying problem here). Imposing more process will not fix the team not caring about the product / business.
If you are not up to changing jobs, I'd suggest you try openly bringing up your concerns in a retro. Unless, you actually don't care about the product yourself either?
The colleagues in question are all gone now - they got better jobs thanks to the mess they've created in my project...
Psychopaty is perhaps too strong a word - they're just taking care of their interests. Perhaps in the olden times they were aligned with the interest of the employer, but currently they're clearly not (my employer has just announced that they'll lay off a couple hundred of IT people are replace them with an Indian outsourcing company, purely to cut costs...).
I don't care about the project either, but as a tech lead, I'm actually paid very well by the company to take care of its interests - incl. killing off any wild ideas that the devs might have. This (staying on old and boring tech that works well, but is not what will help me get the next well-paid job) will hurt my career in the long run, but my plan is to actually go FIRE within the current job, so it's not a problem. Most people don't have such plans though and hence they don't benefit from toiling for an ok wage with boring tech that gets the job done.
The underlying systemic problem is of course the fact that the whole industry (at least here in Europe) is crazy about following the latest tech trends for trends sake, and thus running along on the tech treadmill is the best way to get highest compensation. In the US I believe it's different, because there joining a FAANG gets you the most money, and they mostly use custom tech anyway, so they don't care about the latest open source hits (of course, you have to leetcode instead, so it comes with its own set of problems).
> my employer has just announced that they'll lay off a couple hundred of IT people are replace them with an Indian outsourcing company, purely to cut costs
Not one large-sized Nordic bank by any chance? ;)
The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left. But I am certainly not denying that hiring devs who are willing to commit to the business is a really hard problem. Companies should maybe focus this more in their hiring practices over just the technical skill profile. Good developers will learn the tech stack in the job, if they care.
Also, people retention / satisfaction is pivotal in keeping the commited people on board. Doing massive outsourcings to India is certainly not a good signal to send to those who feel their skills and commitment could be appreciated elsewhere as well.
> Not one large-sized Nordic bank by any chance? ;)
I will say no more ;)
> The flipside of using latest tech is you should have easier time hiring new people to replace the ones who left.
I've heard this argument before and it's basically a non sequitur for me. For example, there are fewer people who know the latest and greatest Scala libraries than those who know for example Java 8. The people who have learned Java 8 have not died or retired yet - they are still in industry, in large numbers, and hence it's easier and cheaper to hire them. Whereas you have to fight for the bleeding edge guys - usually by offering them high-paying contracts (which are the reason half of these guys are following the bleeding edge trends in the first place...).
the problem exists too in the US due to large amounts of venture capital lying around. Ask yourself why many startups run on K8's yet they don't have the SRE requirements google has. Too much resume padding.
Good luck, if you're a engineer trying to make things work without too much ceremony. everything is about chasing the latest and the greatest, whether it makes sense for the problem at hand or not.
> I find a lot of devs who dislike scrum dislike being told they have to work on company priorities instead of giving open ended estimates
No, what I dislike is being told to go work on feature X, when I know that we’re going to run into issues with feature Y in a matter of weeks, and then having to spend nights and weekends fixing it when it eventually does break, because nobody trusted me to know what was good for the product.
Scrum gives people who have no clue what they’re doing the illusion that they do. The process is literally their only handhold to avoid feeling swept away. Like, I’m doing nothing else right, but at least we are following _the process_.
In Scrum the PO state what value they would like to see in the next sprint. Then the team start to pull in issues supporting that value. If you know that feature Y is going to result in none working software any PO pulling his/her weight will listen to you. After all, working software is more important that a new feature.
Again and again I've gone into the details of people's criticisms of scrum, and again and again it's turned out that they were just not actually doing it. Actually doing scrum does work 100% of the time as far as I can tell.
And on the other hand, you have a lot of testimonies here that say the only places they saw scrum work was when it was adapted to the team, and the ones that followed it to the letter failed.
It can't be both things at the same time. (out of curiosity, you say 100% of the time, how many companies you worked for that did scrum perfectly and had 100% good results?)
I don't think that's a fair assessment. There are definitions of scrum methodologies. I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them. All of them "compromised" with other business interests, and typically the compromise was on the "hard to follow" parts -- the core tenets of scrum! Some of them were 100% waterfall, but with scheduled meetings bearing titles that mimicked scrum processes. These aren't "people doing scrum wrong", these are people in a cargo cult.
I have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful.
* Sprint planning has to be mutual. Management cannot plan a sprint on their own, they do not have enough information to accurately plan for order or operations or effort required. Furthermore, participants need to understand the direction and priorities of the project in order to do their job properly.
* You cannot change a sprint that is in progress. Mitigating switching costs are a huge part of the benefit scrum provides. Compromising on this defeats the point of the process. It's hard to tell management "no", but you have to do it. If fire-drills are unavoidable, then you must to account for this time when you plan a sprint.
* All stakeholders must attend backlog groomings and sprint reviews. If the inputs to the process are guesses, then the outputs will be guesses. This is just as important when prioritizing work items as it is when giving feedback on completed items. It must be first-hand. Documentation and/or status updates simply do not even come even 10% close to the power that a live demo does.
> I too have worked many places that did not have success with scrum -- all of them had one thing in common, they didn't actually follow one of them
To me that approach goes against the original principles for agile, especially "Individuals and Interactions over Processes and Tools". I'm not a huge fan of highly structured Agile and scrum processes. But I think the best agile implementations come when teams have ownership over their own agile processes.
And if the team truly has ownership they are responsible for their success or failure. Sure, their process may be objectively bad, but that doesn't mean a better process should be imposed from outside of the team. The team should have some level of trust to fix it.
I also disagree with your three points being hard requirements. They may be really good suggestions for teams doing scrum, especially in lower trust environments. All three are specifically for scrum, for instance they lose meaning if you aren't doing sprints. But that's just arguing semantics. Fixing compromised scrum isn't strictly necessary if the team can be successful by dropping scrum.
Bear in mind I was speaking specifically about following scrum. While agile is flexible and open ended, scrum is a specific way to implement agile, and it has a process.
If, for instance, you’re not doing time-bounded sprints, you are objectively not doing scrum. Scrum has an implementation guide that outlines this.
> While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Many people borrow ideas from scrum for use in their homegrown agile solution, and that’s ok. But it’s not scrum.
Define "the wrong things." I see a year or two of productive work before I'd have to reach for anything with genuine doubts about business value. I might not read my stakeholders' minds exactly, or hit their preferred ordering, but I know they'd be consistently happy with the changes.
Ownership and vision are kind of the point of midlevel and senior roles. If you'd fall off the track in a matter of weeks, something is seriously wrong.
Do you think that’s representative of most work in most businesses, that you could work for months and years and finish things sort of in whatever order you want? Most of my experience has been that the planning and priorities of the business are much more strict and immediate, and you need constant interaction between them and the technical people to deliver the right things in the right order, and hopefully at approximately the right time. Business goals come frome outside the technical teams, they’re seldon determined by the devs, no matter how senior.
I think that’s more or less what it means to work in a tech company, as opposed to an IT department. “The business” is not some external thing. Each org is responsible for some part of the business, and contains all the specialties needed to take care of it. Junior people may work only within their specialties, but senior people are expected to have close partnerships and shared understanding with their cross-functional counterparts. We talk with each other frequently, but few of those exchanges contain anything new or surprising. Usually just an agreement to do the obvious next steps relative to what we did last time.
Agile/scrum is not about software development. It's about business agility, managing uncertainty, and being able to adopt what you're doing to new information and new market situations.
You can't design, review and test new product designs in a word document. You need to be able to iterate, learn, adopt. PDCA: Plan, Do, Check, Act.
Scrum is just a framework that implements this. Main benefit for the business is that you don't have long periods where you can't change where you're going. And if you change your mind, you don't want to have to throw away a lot of useless investment. So you only plan short sprints, you deliver quickly, generate ROI, and improve your plan where you're heading.
Er... the scrum specific ceremonies are supposed to be a starting point for a team. The point of retros is to adapt your process to the team's needs as you go. So if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting.
Scrum and all agile processes are owned by the development team (including the PO). If they're imposing a cost and not bringing value to the developers, you're supposed to change them.
