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.
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.
> 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.
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.
Tasks should be used for communication of priorities and so forth, but they're often treated as stone tablets passed down from the mountain.
I accept that not everyone's like me, though.
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.
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.
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).
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.
The implication that this is “the solution” is pretty naive.
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?
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.
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.
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.
Plus not everyone has the privilege of a good base experience, or the option to just find a better cultured company.
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.
The benefit of having a single PO is that they reconcile the competing priorities and the developers don't have to do it themselves.
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.
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.
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.
Using scrum/agile to fix a lack of trust, not sure how that's going to work out long-term.
How do you work as a professional autonomously without setting rules for work and setting up process for regular progress check-in?
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.
Maybe the answer is just 'hire better engineers'. Where better means they're good at the product decisions too.
- 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)
(edit for formatting)
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.
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.
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?
I like the analogy.
I have a lot of sympathy for this perspective.
I also notice that 90% of everyone does everything wrong.
I don't know how to reconcile those two observations.
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 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.
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.
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.
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.
I'm sorry, but the basis of scrum is the scrum guide, 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).
Can you elaborate on what in the parent comment is not part of scrum?
He likes doing scrum when it’s actually scrum and not “scrum”
We use it to keep things short and focused, since everyone wants to get back to their work and can not do stuff while also taking part in the daily.
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...
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." 
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.
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.
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.
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.
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.
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.
Interesting that it's never mentioned that Jeff Sutherland and Ken Schwaber, the creators of SCRUM both come from the military.
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.
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.
Im sure there are ex-military people who are chill, but ive seen some insane ones running tech verticals in the past.
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.
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.
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?
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 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.
It's the first thing in the agile manifesto. The FIRST.
And yet here you are talking about processes and tools and claiming it's still agile.
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.
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.
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'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.
‘Agile’ gives you the flexibility to determine what that process is. Scrum is a different story.
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’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.
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.
That being said, I do not think from your description you have experienced either SCRUM nor Agile.
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 love this. Mind sharing the name of the company?
IMO: Agile produces worse software but when done correctly with a reasonable boss the work environment it produces is much simpler socially.
How do you, as a product owner, coming up with new features? How do you, as a product owner, prioritize one feature over other?
Agile is at is core just some suggestions for teams to work well together. There are no stand ups or sprints or whatever.
Scrum was created by one of the creators of the agile manifesto as a way to see consulting/training around the 'Agile' idea (timeframes may differ a bit, but they were linked). There is an interview/article by one of the creators of the agile manifesto (Kent Beck maybe?, will try to dig it up and edit the answer if I find -> was Robert C. Martin, see below) where he explains a bit the story and compares it to Agile (and basically says scrum has nothing to do with the original agile manifesto)
On a personal level, I hate scrum. The stand ups, the sprints, the retros or grooming or whatever they have nowadays. It is literally one of the first questions I ask in an interview about their processes and excuse myself from the process if I see if they follow it. It may work for others, but for me personally, I hate it with a fervour.
Though I agree with the Agile manifesto though, unfortunately it isn't very 'manager' friendly so you usually get scrum instead.
Edit: link to a reference to the article, can't find the original but found this: https://www.aaron-gray.com/a-criticism-of-scrum/#scrum-strai...
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.
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".
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.
That seems like a bad culture more than anything else.
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.
I understand your take, thanks for the contrast.
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.
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'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.
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)
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.
'The expert' may turn out to be the junior you just hired.
It's also about flagging issues. Sometimes 'This is not working' is not synonymous with '...because I haven't figured out how to do it.'
It can also mean 'This is actually broken' and the team hasn't realised.
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.
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.
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 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".
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.
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.
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.
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 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.
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.
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.
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!
Looks like we need to agree to disagree here.
See: Are Disagreements Honest? by Tyler Cowen & Robin Hanson, 2002
>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.
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.
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.
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.
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.
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.
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.
That has always sounded super pretentious to me. It's a damn meeting, not a wedding or a funeral.
Agile seems very ceremonious to me.
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.
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....
At best you get the chance of feedback with nothing implemented out of it.
Why is your manager present at the stand-up? It's just for the developers.
Sprints are just the periods of time between retros.
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.
> 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.
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.
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.
That's probably why some managers like it.
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.
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 actually created by two Japanese dudes , and was for the manufacturing industry.
While we’re on the topic of Agile, though, it’s best not to forget its eXtreme Programming roots.
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.
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.
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.
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.
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.
Again, thank you!
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.
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
Here is the readable on the web version: https://basecamp.com/shapeup/webbook
Obligatory PDF: https://basecamp.com/shapeup/shape-up.pdf
Shape Up Your Agile (article): https://thinkfractional.blog/shape-up-your-agile/
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.
But it was a process we decided on as a team, not something a consultant had read in a book.
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.
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.
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).
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.
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.)
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.
Is it possible to fall in love with someone so quickly over one line written on the web?
I can't wrap my head around this. The first item of the agile manifesto literally says:
Individuals and interactions over processes and tools
> 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.
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:
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.
F1 F2 F3 Desi Impl Vali
In Agile, you progress through the grid left to right. First you work on feature 1, doing design, implementation and validation, and only then 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.
Do you abruptly cut the interview short or do you just make a mental note and continue?
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 :)
I LOVE sending letters like this. It's the politest middle finger you can give to a douchey hiring manager or organization.
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.
Typically, they just become another box to check. “This task is underway, blah, blah..” and everyone tunes out.
I’ve seen them done well and usually because they are focused on prioritization - “is this still important? No? Stop doing it”.
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.
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.
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.
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.
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?
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).
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.
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...).
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.
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_.
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 have only worked with a single team that fully followed a scrum methodology, but it was very eye opening and successful.
How many of your bad experiences with scrum bent more than a couple of these rules? How many were always followed? : https://en.wikipedia.org/wiki/Scrum_%28software_development%...
Some big things I've learned are:
* 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.
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.
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.
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.
What do you call it if everyone is doing it wrong?
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.
Just a way to manage uncertainty.
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.
And then, based on the comments seeing here, you are doing it wrong because
>if your experience of standups, plannings, retros etc is bad it is by definition because they were doing bullshit scrum and not adapting.
I'm sure some super special orgs out there can counteract this with their incredible non-toxic culture and such. Most cannot. Ones that explicitly think they can almost certainly actually cannot.
If it's solely the IC's, I think that's where it can be good. People feel a lot more free to not say anything if they don't have any blockers and don't need to put anything to the team. It's much easier to get in-and-out and have a high-bandwidth discussion.
I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next. And we had an open-door policy (not literally/physically of course) if you ever needed to discuss blockers or put things to the team. "Standups" happened naturally, about once or twice as week, where people would accrete into a standup in the middle of our pod discussing something that was so interesting/relevant that it naturally drew us out of our offices.
Maybe that was just the only time where we finally had the team and the process mesh on a natural level, and it doesn't prescribe this as "the way to do it" for anyone else. But damn did it work for us, for at least two years, before the org changed enough that our team didn't really exist as the same team anymore.
One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible". That and everything related to it was awful.
I've done daily stand-ups/check-ins either end of day or first thing in the morning for nearly my entire career. I've also been fortunate enough to have good team members and technical management (prior to being management).
I have always found them helpful, particularly when people get stuck. Of course someone can always shout I'm stuck and hope the right person hears, but I've lost count of the times someone in the standup that likely would not have seen this person's problem says 'oh, I've seen that - do this'. And that includes possible management. Also, many people don't want to say they are stuck or don't know something. While not automatic, this does provide a scheduled block of time to speak up.
I've worked with many great engineer people who had tendencies to go down rabbit holes. A daily check-in made micromanagement unnecessary because it forced someone to think about what they accomplished and where was it headed.
Finally, it's ok to say nothing was accomplished yesterday. Shit happens, we all know it.
I'm curious how bigs were your teams? and if you were all local in the same office?
There was one place were we did daily check-in and it was okay. It wasn't formals stand-ups but an informal check-in in the morning, asking each other what's up, when we got to our shared office, right after breakfast. We were just three in the team and it was quite informal. The majority of the time there weren't the three of us in office so this really wasn't a meeting at all.
Most of the industry is doing it wrong/cargo-culting the wrong think. Non-technical managers, or worse, CS grads whose goal was to stop coding 4 years into their careers, took the parts of Agile they liked and made it into a micro-management strategy to justify their work.
Agile was written at a resort by 10x engineers for 10x engineers. Flat organization and high ownership (meaning these guys have a stake in the company). Trying to blindly copy it to highly hierarchical cost-center software shops is a recipe for disaster where the only ones making money are the agile consultants.
Do these 10x engineers need Scrum ? I don’t think flat/high ownership organization have a strong need to be told how to do things, or import some cookie cutter framework in their day to day operation.
Getting inspired ? sure, but a lot of the ceremony parts of Scrum don’t make sense if people already communicate fluently and organize seemlessly.
Not to beat a dead horse one more time, but "Agile <> Scrum"
Scrum is just one, out of many methodologies that claim some association with the core ideas behind the Agile Manifesto. It's totally possible to be "Agile" and not do a single thing that's in Scrum.
And just to add one more note: there's a lot of "stuff" that gets lumped in with Scrum in a lot of these criticism heavy threads, that isn't actually part of Scrum per-se. Often times idiot would-be Scrum masters cobble together bits and piece of ideas here and there and make some goofy hodge-podge and then call it Scrum. I'd encourage anybody contemplating Scrum for whatever reason to go read the Scrum Guide and see how different it is from the "Scrum" their organization practices. Same for the Agile Manifesto.
And if you encounter an organization that claims to be doing SAFE (Scaled Agile Framework) turn and run away as fast as you can, IMO.
It's more of a set of ideas that can can be applied to a project (or not) and ways of thinking about the software engineering process itself. It's not a magic recipe, just like no programming language or framework will make RandomCo. a unicorn.
and, I'd like to point out, Agile/Scrum is great IF applied on suitable organizations/projects.
Some projects are too big by nature and, regardless of how much resources are available, there are not enough 10x engineers to be hired and trained to deliver the project within a feasible time.
Some organizations are too hierarchical and there's no way to change entire cultures based solely on software projects' needs. By extension, its employees are unlikely to show the level of ownership required by Agile.
Don't get me wrong, I like Agile and favor it over other method families whenever I can, but I have a different point of view when it comes to organizations "not well-suited to Agile". I don't necessarily see them as limited solely based on how well software projects can be carried within their structures.
It's indeed advantageous to possess a software project-friendly environment. That would provide them a good edge over competition.
But there are so many other things beyond that, and so many organizations being successful on their main goals despite being Agile-hostile, that I'm more inclined to look for ways to cope with their shortcomings.
I'm not implying you wanted to say that, but I see many Agile enthusiasts classifying those organizations as "not prepared to Agile" and I think this is so wrong. I see that simply as a natural incompatibility and, if I had to elect a culprit (which I don't think to be the case), then Agile would be the party which is in debt.
These two issues can be solved by isolating the software folks from the rest of the organization. Think of a company within a company. That and fixing the hiring pipeline can fix ownership: bringing a culture of stock based compensation typically attracts high achievers and make it important for the engineers to truly own the product.
You could structure your IT department as a flat organization (and I think it's indeed a good idea), but how would you fully adopt agile principles when they consider users as part of the team? How would you favor interactions over processes while stakeholders from the other side manifest low ownership levels or even sabotage the project (if they see the project putting their jobs at risk or when their managers don't give the project a proper level of priority)?
In theory it makes sense, but experience shows it's impractical to apply Agile principles on such environments without some adaptation.
I've already worked under such arrange (scrum + flat IT department inside hierarchical organization). It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
If software engineers are working as the "IT" department, it's already a red flag. Especially if it's treated as a cost-center.
> It worked great for my project, but I was lucky to work with a competent and collaborative key user. On the other hand, some colleagues of mine faced issues. I suspect that their projects would have been more successful under a different, slightly more bureaucratic approach, given the sort of users they were working with
Some users, especially internals, don't want any changes. when that happens, the only thing left to do is pretty much switch project sadly. With a stock compensation, you don't want to waste your time building something that won't be used: that doesn't create any value.
(More precisely, in Scrum there is actually no such thing as a manager. But often the manager is a replacement for product owner. However, the product owner should not be present during the daily stand-up. It should only be developers talking to developers, with scrum master acting as a moderator, essentially reminding everyone to keep it short.)
> I've felt the most comfortable where we sat down once a week for an hour, went over the last week, and thought about the next.
In Scrum, this is called retrospective, and is considered the only non-optional part. Ironically, in most companies this is the only part of Scrum that gets removed as a "waste of time".
> One thing I have never enjoyed was the "the big boss wants this project done ASAP, have standups every day to make sure it gets done as fast as possible".
This is what Scrum is explicitly against. The big boss should not even be involved; the developers should be talking to the customer directly. The customer decides what is the highest priority, but the developers decide how long it will take. The entire purpose of planning is to negotiate this; like the customer says "I want X and Y", the developers say "we can't do both in one month, but either of them is doable alone, which one is more urgent for you", the customer says "in that case, I want X", and the developers say "okay, let's meet in a month, you will have X, and we will show you a demo".
A little bit of social exposure helps everyone to be their best selves. Mad respect to people who truly don't need this. But it makes sense that the workplace is adapted for those who do.
I'm old and I worked at Ingres when they decided to write a new release and everyone went off and worked on it for a year. It was right on schedule. Then they got together to release the product and found that each team had developed a component that failed completely to interoperate with any other components. Have you ever heard of Ingres?
The key to their failure was that they never put the pieces together.
So agile is a bunch of techniques to let people work together on exceedingly complex projects. Calling it agile is indeed just marketing. It is basically a messaging bus. The idea is that those Ingres people could have had some meetings to talk about how their components worked and things would have been better. Maybe not great, but better.
And if those people understood that their goal was to give others insight into how they were doing things, that would have been even better.
But think about this - what if from the very first day they just ran the whole project with all the components? Even if all the functionality was stubbed out, at least they would know that it worked together. We do that now, or we should - continuous integration or whatever.
I knew a person who was a great person and great programmer who had worked in the industry for eight years. And not once had the product they worked been used by another person. Think of all that waste.
So yeah, ignore scrum and agile and all that if you have something better. Its not a religion, its just one way of working together. :-)
> So agile is a bunch of techniques to let people work together
Never integrating the parts until the end has nothing to do with not having used "agile". It's just terrible engineering.
Quality engineering work has been getting done for decades before the agile cargo cult of daily status meetings aka "agile".
I don't disagree with this exactly, but agile is/can be a useful tool to keep engineering on the rails. It's not like if you do agile, you can forget about engineering practices because you've got agile instead. It just reinforces why good engineering is important, and acts as a stick to keep engineering teams on track. A bit like how with good tests, you just can't get away with sloppy code, because having tests necessitates following best practices.
My first experience with seeing how effective this communication can be was before agile when a manager held short, goofy meetings once a week and we engineers somehow managed to ship, ship on time, and ship reasonable products.
Only because of HN comments talking about the history of Postgres!
Agility is just what it says: a philosophy of flexibility and adaptiveness.
Heirarchies, heavy processes, etc are by definition inflexible. They are not agile. You do not do agile. You are agile. You are agile because your company has a culture that is agile and you cannot achieve that unless the company is structured to be flexible.
I think actual agility is really, really a great way to build software efficiently... but unfortunately most programmers will only experience the cargo cult forced upon them by certified scrum masters... and this is just as bad, perhaps worse, than old fashioned waterfall.
More than anything, working in an agile environment is a very pleasant thing to do from a human standpoint. But most companies are incapable of the kind of equality and empowerment necessary to achieve agility, so they will force the terrible cargo cult version upon us.
We still had retros and dailies. Planning was done by managers explaining a feature they'd like us to do, and the team then doing the planning, design and implementation. More processes and e.g. recurring meetings were erected and torn down based on the team's actual needs alone. If someone wanted an estimate, we'd give it, but we were not doing continuos estimation just for the sake of estimation itself, like in Scrum. Felt like the process served us, rather than us serving a process. If you'd taken a look at the Agile manifesto, we were ticking pretty much all the boxes: https://agilemanifesto.org/principles.html
Then 1.5 years ago, company decided to roll out whole IT department wide SAFe, which is basically Scrum but on a whole organization level, and hence even more bureaucratic and with one additional level of mega-iterations added on top of Scrum's sprints.
Suddenly, our team is assigned a Scrum master and we no longer even get to speak directly with the managers who previously negotiated new features with us. Instead, everything has to go through multiple levels of prioritization and broken telephones of new SAFe intermediaries. We started attending 2-3 new mandatory processes / recurring meetings, meaning time spent in inefficient boring meetings went up significantly. We had to also start a much more stringent ticketing system regime, including having to estimate ALL work. Despite multiple requests from Scrum master and managers, nobody was ever able to explain why estimating absolutely everything - even when nobody had even asked for an estimate - helped with anything. It was seemingly taken as a religious thesis that it was just the right thing to do.
Soon, the team was paralyzed. Even simple features became harder and harder to develop. Despite the massive effort spent on estimating even the most trivial of tasks, the big picture was forgotten about because larger feature-level ballpark estimates were no longer acceptable, and hence unimportant. On a company level, the business managers that previously talked directly to us just basically quit working with the IT department because the SAFe process was such a beast to contend. It was easiest for them to just stop asking for new digital product features, and focus on non-IT projects instead.
I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way - Scrum consultants love to gloat when some metric improves, but if things go south the org has only itself to blame for failing to correctly convert to their favorite flavor of True Agile System™.
My experience was however seeing an Agile team (as expressed by the Agile manifesto) turn into a Monty Python parody of agile software development just by being forced to submit to these "fake agile" heavy processes and hierarchies.
I guess you just weren't Agileing and Scruming hard enough!
There are a set of ‘good things’ that I can see from SAFe, and if you read the book and do the course there is loads about how you /should/ adapt it to work for you.
Amongst the issues is that SAFe, by its very nature, has stakeholders outside the local team and that mandates some sort of process.
Interestingly the size that Scaled Agile talk about is pretty big - a small Agile Release Train was discussed as ~100 people across ~5 teams. The full Portfolio SAFe is for multiple release trains e.g. 500+ people.
If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong.
Also, if the “IT Department is trying to implement SAFe” rather than the “Company is undergoing a SAFe transformation” it has already gone wrong. You need to have your stakeholders throughout the organisation on board, and it is something of a top down thing.
Is this really happeninig in your org when adopting SAFe? At least for us - we went to all the trainings but it was essentially a two-day heavy course of a SAFe consultant telling us how to run dailies, groomings, plannings, PI plannings, retros, demos etc. etc. ALL of these were mandatory and our team was assigned a Scrum master to make sure we were actually doing them (granted, he took responsibility of organizing also the retros, which was previously a full workday for me every two months.)
I even remember reading from the SAFe book that teams are only afforded a limited autonomy of deciding on the implementation technologies of the features that are assigned. No word of having any autonomy over the process, since I understod the uniform process being a requirement for the inter-team coordination to work.
the comment you are answering was on point
>I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way
If you want to lose weight, a diet where you can eat as much McDonald’s as you want is probably doing it wrong. Applying SAFe to a small team is probably wrong.
sledgehammer to crack a nut.
Reality is of course that the dev teams are the only ones ever trained in the new process, and must suffer the chaos while rest of the org just don't care or hate it just as much – apart of course from the new middle managers who were hired to "help with the SAFe transformation".
My prediction: max two years from now senior management announce "the end of the SAFe experiment", and go back to some ad-hoc version of the preceding organization model "with lessons learned" etc. Rinse and repeat every four-five years.
Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers:
* know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement;
* at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted;
* reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira);
* decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast";
* make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day.
If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.)
So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this:
The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes.
This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.
That's the gold standard! You know you are doing fake agile when the team is not allowed to decide stop using Jira.
In all seriousness, thanks - very valued insights! I did not even know those were the original purposes of the Scrum ceremonies, having only ever worked witn almost exactly the kind of pseudo-Scrum you describe.
This is the moment you know you are doing fake Agile and your scrummaster is just the managers puppet in disguise to spy on the team.
I am not sure what would be the right solution. One possibility is to fire the management, or never even hire them at first place -- if you want to have a software company that uses Scrum, do it from start. Another possibility is to have a Scrum Master with strong political skils... which more or less means, it cannot be a former developer.
Probably the fatal mistake is having too many managers in the company. At that moment, it is practically guaranteed that they will try to interfere with everything. They have to, because that is how they protect their own jobs. And they will hire more managers, because that is one way to get higher on the company ladder (hire more people into positions below you). And at that moment, everything is doomed, because now the company serves the managers instead of the other way round.
I guess this means that Scrum can work as intended only in small companies. Where the Scrum Master is not below several layers of management, but on the same level as the few managers, right below the company owner.
I would argue that most companies cannot afford to give that kind of "empowerment" to most developers, especially if these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals.
Now I'm not saying that's how it should be, but that's the reality of the software talent market today.
The problem is that this means you need leaders—managers or not—who are comfortable without an illusion of control or visibility and who understand how to lead and communicate effectively. And you really need this all the way up the chain. If you manage this, though, you'll be amazed at how productive even heavily junior teams can be.
Development isn’t an assembly line process—and cannot possibly be. It’s about theory building and mental models. It requires experience.
It’s fine to have juniors, but they need to lean heavily on experienced colleagues. No amount of management and no management process can change that. A team where the juniors outnumber the seniors 3-to-1 is going to cost more money in the long run.
What you’re describing is exactly what I’m talking about when I say companies are unable to achieve this. Hire 3 senior people instead of 12 junior. You’ll get more done. Reduce your collaboration costs. But, as a manager, you get paid more if you manage more people, or if the people below you manage more people, so there’s a perverse incentive to build as much bureaucracy as possible and staff the lowest layers with the cheapest possible hires.
Personally I'd almost always rather hire a single senior engineer and pay them what two juniors make. I suspect I won't get double the JIRA throughput, but will get more than double the actual effect on the product.
Anyone who says the Agile Manifesto and Scrum are not directly at odds is trying to sell you something.
If you never seen this, you should read this ASAP: https://agilemanifesto.org/
Because that's all there is to know about Agile. Obviously it takes a bit more time to really grasp how can you translate that to lines of code or building a deployment pipeline or shipping features, but if you understand these couple of lines, you already know enough about agile development.
“Kids today don’t know” what it feels like, explaining lawyers how you didn’t feel the wind turning after spending 9 months delivering layer 1 and 2 and crossing your fingers that layer 3 will be a wrap-up. Once you have seen that, the “less paperwork, more interactions”, the “add value not layers” become a relief ;)
But more seriously, "agile", what does it even mean? I almost posted this on another comment.
There is no, singular, agile beyond the manifesto. Everything else is a variation either attempting to push the goals and ideas of the manifesto or attempting to capitalize on fads.
Scrum is borderline fad (I'm ok on the concept, but I think employees should be paid not to go to most Scrum classes; most implementations are incredibly badly done like they deliberately misread the guide). SAFe is bullshit (the gov't bought into it though, how's that F-35 coming along again?).
XP had (has?) some seriously dogmatic advocates, but most people have learned it's a toolkit and not a thing to do without consideration.
Lean has always been presented as a philosophy and toolkit, at least as far as everything I've ever been able to find on it. I think there are some moronic certifications out there, skip them.
DevOps is Theory of Constraints for IT. Which is not a set of ceremonies to perform, but a way of viewing and trying to improve the system. Though, like with Lean, many people are apparently illiterate and fuck it up.
So the question becomes: what version of "agile" were you using? And did you do one of the most important thing that, as I noted in another comment, seems to be the most crucial common element of most of these (except SAFe, fuck SAFe): Did you actively set about to improve the way you worked as you worked? Did you frequently ask questions like: Is this working for us? Is this working for our customers? Is this the right process? Are these the right tools? Are we holding it right or should we try something different?
If introspection and reflection and periodic adjustments to not just the product but also the team (structure and dynamics) and processes aren't in play, then it's probably a ritualized version of agile which is only barely better than Waterfall.
Very high quality engineering work has been getting done ages before "agile" status-reporting was invented and it was often not waterfall (I've been around the industry since the 80s and have never done "waterfall" - the false dichotomy of agile vs. waterfall is a myth).
Much like TDD, which works great when it’s dev driven, agile works great when it’s driven by dev team.
The problem happens when the PMs get involved and they have to schedule meetings to get basic status updates and have to implement their voodoo rituals to make it look like PMs are adding to project velocity. Planning Poker, lol.
It gets much worse on larger scope projects and many devs and PMs are inexperienced.
SAFe has a great, telling name though - it's designed to be safe for corporate control freaks. They might not know waterfall, they just live it in their guts.
Easy to identify, they believe in being a "visionary leader" and "inspiring the lower rank".
If you have an inexperienced team, any process you adopt is going to suck.
Talking with a customer was great when we could, usually it's been when I worked in a small team (1-3 developers), speaking with either internal or external customers. We talk through what is needed then the BA/PM documents it in the updated job brief, rather than the other way around which leads to so much back and forth. It gets to the root of any uncertainty about what they want much quicker.
This is not any official brand of Agile. It's just our natural inclination when left alone. Talk, iterate, deliver.
I'd rather have multiple Sr. Devs be half time management, and half time dev. Or increase Sr. Dev pay by 20-30% and have them pick up management on top of their duties.
Sprints conceptually make sense. We have 3 features we want to develop. Lets aim to complete them in the next 2-3 weeks. I like them so long as the goals are extremly well defined and managed. Too many teams though forget the agile aspect of agile development. If there's a change to the priorities, its often poorly communicated or just added to the sprint without removing anything.
Daily Standups, as practiced by most teams, are a waste of time. They become status updates for the Project Manager or Team Leader.
What would be better is for engineers to use the time to review ideas, issues that have cropped up and ask questions about the codebase or specific issues. This is probably what a standup is supposed to be but when its mixed in with the context of status updates, it always takes a back seat.
Pointing is a complete waste of time. I have no idea how long a ticket is going to take until I start working on it. Estimations are usually wrong anyway. If anything, tickets should be pointed once the work is complete to track a teams acutal performance and velocity (output).
Having the team review tickets for the next sprint (sprint planning) is useful for inital discovery (so long as it doesn't involve pointing). One person on your team might know how to solve a bug ticket or know if a feature ticket is deceptively difficult. That discovery process can be extremely valuable.
Overall agile ideas I think do help more than they hurt but not always and not by much.
It's a complete waste of time for developers, but unfortunately the rest of the company might need to have an idea how long something might take because they need to sell products or services, and get return on investment.
It's really hard to sell people on "we will do these features/this project, but we have no idea how long it will take so just pay us until it's done". It's much easier to work on your estimations until they always get a little over-estimated, and then sell those estimations to the people paying the bills.
What would be far better is if in sprint planning, tickets were properly split into blockers and improvements (effectively the same as needs vs wants).
Its up to you and your team to help the PM understand what is likely to be completed in a given sprint between the needs and wants and what will rollover to the next (maybe some of those needs are actually wants, and some of those wants are actually needs - this is part of what sprint planning should involve). Part of that is also the PM communicating what needs to get done (and vice versa). Pointing is just a more arbitrary and lengthy means of having that conversation.
Sprint planning is useful, pointing does nothing. If a blocker ticket is in the current sprint there should be a good faith assumption that it will be taken care of. If something happens putting that deliverable at risk, that's where the line 'people over processes' matters more and you have to communicate what issues are preventing the team from completing the blocker.
I guess I'm trying to say. Pointing as a process is a waste of time and the information it conveys can be conveyed more efficiently with good communication with your PM and team and a decent amount of trust between engineering and external teams.
The points are purely to get an indicative size of the work, so it is clear work will be done in the next iteration (e.g. 3 weeks).
If other teams within your organisation need to know when an item is likely to be completed then accurate estimation is useful.
If the feature or task takes longer than the allotted time, you get to be agile and reevaluate if you should continue on the feature (does it need just a bit more work) or if its something to come back to in the next cycle.
Just like you say. If something takes longer than expected in the sprint, the retro is the time to call it out, review what happened that made the ticket take longer than expected and share your learnings with the team so everyone is aware of that particular aspect and knows to look out for it next time (maybe it was waiting on another team that blocked you, an unseen complexity, a changing requirement etc).
I never actually saw it that way. It's more like we know the velocity of the team is about 25 to 30 points based on past estimations. The team has estimated the following stories and the product owner decides which stories he'd like to see implemented. So he picks a few stories totaling 30 points with the knowledge that it may not get done. And that's supposed to be OK. The more and longer you estimate with the same people, the closer the estimations come to reality. So he has 3 stories totaling 30 points, he definitely wants 2 of them to be finished so he puts them at the top - if the third one doesn't finish then that's too bad but it should be close to done at least.
I've never worked nights just because a PO decided he needed a feature in the sprint. But I'm also the type of developer to say something like alright you want this feature in the sprint that's going on? Sure pick one that's going out or I can assure you it's not going to be finished. I'm not trying to be a dick, but just communicating and managing expectations.
We integrate software every commit.
They did proper integration point releases between teams at various phases, it was more an issue with 1 week sprints to close off tasks resulting in so much overhead that I felt like I was just building momentum and had to stop and gather my thoughts for the retro and planning. We'd essentially lose one work day out of every five.
Something I consider maintenance work is refactoring of systems as new projects are planned/implemented. Everyone knows it’s a bad idea to just bolt on more and more “feature” work without thinking systemically, then we all point at “systemic” issues in retrospective meetings.
Again though, I’m not losing any sleep over this it’s just an observation from 9 years of experience as a web developer working for mostly SV tech companies large and small. It won’t be everyone’s experience, and in general the best advice I can give is try to come up with solutions using your own experience and opinions over those people implicitly/explicitly tell you to follow because they are “good”.
When the great CPU architect Stephen Keller was on Lex Fridman's podcast, he made a comment that architectures should be refactored every 5 years and I thought to myself, "Good luck with that in Enterprise" as I looked over at the 10+ year old legacy infrastructure holding back org-level velocity at work
But in all seriousness - scrum as it is practiced today is not beneficial. It's mostly used for "accountability" rather than the "collaborative/communication" mechanism that it was supposed to be. Add into that situations where product/program management questions every little estimation decision (e.g. do you really need those system guarantees? can we leave automated testing out of the MVP to reduce story points).
Agile has been corporatized (if such a word exists) and is no longer "agile".
Too often though in practice it devolves into a kind of cargo cult and the apologists lean way too hard into the "if it isn't working, you must not have believed in it hard enough" defense which is a bit too easy in my opinion. It short circuits any actual reflection and learning.
Basically, the agile manifesto is great.. the stuff agile coaches try to sell you is hot garbage. Everything else is somewhere in the middle, but Kanban is the closest because it preserves the "we are uncovering" part of the manifesto.
Scrum agile works when...
- People keep standup updates short and sweet, so standups take 15 minutes or less.
- Your team has a single product owner who speaks to customers and is empowered to make decisions.
- Team members invest time and energy into backlog grooming/refinement, ensuring stories are thorough and have good requirements.
- The team retros regularly to address issues.
- The team communicates often outside of the regular ceremonies, so that meetings stay focused.
Scrum works poorly when...
- Standups turn into 30 minute to 1 hour "status" meetings where everyone brings up every question they have.
- The product owner isn't empowered to make decisions, or your team has multiple product owners who decide by committee.
- Team members are disengaged or not even consulted during backlog refinement, and stories are missing critical requirements that you have to deal with in the middle of the sprint.
- Retros get cut because "there's not enough time".
- Nobody talks outside of the regular ceremonies, so meetings drag on forever.
Scrum agile doesn't work for every organization and every project. Sometimes company culture is too hard to change. Sometimes the work you're doing can't really be done in an agile way. Sometimes the organizational structure makes it hard for a scrum team to work without consulting multiple layers of bureaucracy. (That's my project right now, and it is NOT fun.) When that happens, you have to either relax the rules of scrum (being careful to avoid the pitfalls I mentioned above), or adopt a different process altogether.
Value prop = You don’t really need this
Data Science = Not a Real Science
I have it more or less working = It’s not working
I got it working = Please don’t ask me about this anymore
Does this make sense? = Are you even listening?
Let’s stop talking about talking about the issue = We’re halfway through this meeting
Please enter a jira estimate = I am or want to be your boss
Quick stand-up = I’m interrupting your flow
Daily stand-up = I’m interrupting your flow every day
PM = Tom Smykowski
Product = Paid Intern
Feature complete = See “I have it more or less working”
Deep dive = I have no intention of pursuing this
In-flight = I enjoy dramatizing the trivial (See “How Can We Land the Plane”)
This is not intended to offend anyone = This probably offends everyone
Big Data = an Excel spreadsheet
Decentralised = not our problem
Open-source = we didn't build it
No-code = I didn't want to pay a programmer
If you want to listen to a couple of guys I used to work with who really know what they are talking about, check out this series: https://www.youtube.com/channel/UC758reHaPAeEixmCjWIbsOA/vid...
You aren't, and that's the grift.
I force developers to do something they are bad at. They get better, but they're never 'great' at it. So I can withhold raises they deserve because I'm punishing them for what they're not good at instead of rewarding them for what they are great at.
So reality trumps ideals.
This was my complaint of the term “velocity” because it sounds objective and absolute when it’s really much more arbitrary and not even comparable to the same team from year to year.
But I think that would get thrown out at the first sign of trouble. In many companies if the anonymous survey showed we were behind schedule the fix would be to stop doing the anonymous surveys.
This article gave me clarity between the two philosophies. Kanban is about perfecting the process and trusting that results will naturally come as a result of that process. Agile is about attaining the outcomes and then focusing on what works for those outcomes.
I agree that Kanban makes more sense but Agile allows managers to point the finger at devs instead of having to point the finger at themselves.
What really gets me about story points are the Agile folks who say "story points are a measure of complexity not effort/time". As if adding more complexity in the same amount of time were a good thing...
In a team of five, we might get 2,5,8,8,20. The value of the estimation was in discovering that someone thinks it's a 20, while someone else thinks it's a 2. They tell the rest of the team why, and we estimate again. Another useful signal is ?,?,?,?,? or (50,50,50,50,50). And of course, 5,5,5,8,8 (or other general agreement) suggests that this is low risk.
You certainly wont hear that from a scrum consultant.
Why? If you made those more detailed estimates and models (which I'm sure would have a significant time cost), what would you do differently based on the results of them?
You need a rough sense of how relatively costly different tasks are, so that you can prioritise - if you ask the business/product side to prioritise completely blind, you'll end up not doing small things that could have brought a lot of value because they assume those things are hard, and you'll spend far too long doing things that they thought would be easy but are actually hard. So you want developers to do just enough estimation to allow the business to prioritise. Which means giving a low-detail estimate and giving developers assurance that it won't be used as a deadline. Story points are the most effective version I've seen.
(I don't watch videos, I'd be happy to read text articles)
Okay, so suppose my best guess is that there is a 10% chance something could be done in a day, 80% chance it would take two or three days, and 10% chance it would take five days. What is supposed to be my "estimate"?
If I keep giving the longest time interval, I will seem like lazy and incompetent, because why am I always saying "five days" to tasks that everyone knows usually take only two or three days. But if I say "three days", then in those 10% when it actually takes five days, I have estimated wrongly.
In a long sprint, this will usually average out somehow; one "three-day" task will take five days, another "three-day" task will take one day. In a short spring, things are less predictable.
(yeah, technically it's not days, it's story points, but the idea is still that "medium complexity" only means "medium complexity unless something unexpected happens" and the unexpected things sometimes do happen, you can't simply commit to unexpected things never happening.)
Estimations from engineers shouldn't be used to forecast when a feature will really be done. That's where the model comes in and probabilities comes in.
I think this is suspicious. It smuggles things from the Old Ways into Agile. Estimation sucked, to a fatal extent, when trying to do critical path analysis of software projects. Why should it suck less in Scrum?
The manifesto mentions retrospectives. Retrospectives have hard reliable data. You can learn from retrospectives. Estimation is unreliable. Would project outcomes actually differ with less emphasis on estimation? Would they improve with more emphasis on retrospectives?
Story points are even worse than man-months at measuring work.
Because in scrum not only is the assumption that the estimate for a task holds not matter who and how many works on it, but dependencies are also not handled well for either tasks or backlog items. To some extent a team can try to handle it in a sprint, but it is not part of the estimation.
For example it can be a lot faster if the same developers can work on corresponding frontend and backend jobs. If they are split in different sprints or if the developers also have to work on other tasks, it could take a lot longer.
And the whole story points, fibonacci, etc is just nonsense. If an experienced developer estimates that a given job would take somewhere between 10 days and two months, depending if they can reuse X and the Y algorithms performs if he and developer Z works on it, then that is the best estimate you will get.
The only thing that makes scrum estimates more precise, is that once you have broken everything into 100 tiny tasks, you have added about 20 hours of writing commit messages, updating JIRA, and preparing for the next task.
I don't know how they do it, but you used to have to group stories to stories of similar effort done in the past in order for the simulation to take into account story size. Otherwise your model will be effected by things like stories in different components taking more effort to do.
Putting stories into rough size pots is essentially what pointing is.
As for sprints: for a few months I have been in a team where there are strictly applied. There is so much time lost: basically the sprint is either too short or too long. After a few "failed" sprints time estimations will become very conservative giving a lot of slack. Personally I am not comfortable with so much slack, it undermines my motivation.
In my experience anyway, as pressure increases sprints are less strictly enforced, for the sake of efficiency. Also approaching delivery the software has become quite complex and bugs tend to be complex has well, hard to estimate precisely. The fact that sprints do not hold under pressure is an indication they are not suitable for SW development.
There is also much time lost in the 2-3 days preparing for the next sprint, because we just cannot spend full days on meetings, for both human and material reasons. Those days are only "half worked".
I'd say this is almost necessary, unless you have a small team that have been working together for a good amount of time, understand the project, and have lots of agile experience. Otherwise, it goes from a status update, to a drawn-out meeting where everyone's got a different agenda, nobody's paying attention to anyone but themselves (count the number of times you hear "sorry, I didn't catch that" when someone's asked a question directly during your next "stand up").
I also find it's really useful to use your kanban/sprint board to direct standup, instead of having each develop take a turn at talking. Going from right-to-left, asking what's changed with each ticket since yesterday, and if there's anything that's blocking progress today.
Of course there is once in a while a "wait wait wait I have already encountered this issue" and someone can help another, but it is rather rare and half the time it is a false alarm because as you said people do not pay much attention.
I really don't get how people come to this conclusion about scrum. The alternative to scrum is the Project manager dictator regime, the literal micromanagers dream, where the pm can at any time jump by your desk and say "drop everything you are doing, and do this thing for me right now", and where the estimates are just whatever the PM decides to communicate, but when you fail to deliver a fully functional product in the 2 months the PM pulled out of thin air, it's somehow your fault.
In Scrum, the PO should be prevented from micromanaging, since he's not telling anyone what to do. There's a product backlog which the PO can prioritize sure, but that's the level of interaction. The team pulls work into the iteration backlog, so nothing should be picked up that the team doesn't agree to do. And each individual team member picks tasks from the iteration backlog, so nothing should be forced upon you. As for the daily stand-ups there should be no management in that meeting, it's a 15 minut maximum meeting between only those who have items in the spring back-log, which most often should not include the PO. If it's turning into a day-by-day status meeting you need your Scrum Master to step in. The board and iteration deliveries should be enough status to go by.
- Standups don't need to be daily - it's too much. Twice a week is okay (this can be adjusted depending on team/product dynamics).
- They shouldn't consist of everyone telling everyone else what they're working on. This practice is boring and useless to anyone who is present. (If you want to check what I'm working on, log into the issue tracking system and look at the tickets against my name.) Instead, standups should focus on pieces of work that need to be delivered or that need to change status.
But this was their personal understanding, and was then removed to pave way for the mandated certified "Agile" methodologies and rituals (=WaterScrumFall). So whatever was learned, gets lost in the next turn of the wheel, inevitably.
What people miss in their accounts is that any success or learning is temporary, and in the organisational space, change is inevitable rendering all and any accomplishments transient.
It's a common habit people fall into when transitioning to scrum. An experienced scrum master should never let this happen though.
A perfect example of this is the misuse of things like story points. It's supposed to be a reference as to how complicated a task is to complete. Ideally, over time, management gets a sense of how many "story points" a team can complete in a sprint. In practice however, development teams basically get brow-beat into treating story points as shorthand for how long they think something will take. So for example, something that involves a bunch of basic drudgery that has no real impact on the system gets scored high. Whereas some minor change deep in the bowels of the system that breaks a cascade of tests and causes massive regressions gets scored low because hey its only 5 lines of code!
Remember the manifesto:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That totally relates to my experience.
I've seen this scene repeated over and over:
- project begins
- something happens and delays the project (arrival of new team members who need some time to learn about the code base, for instance; it's not even an issue, it's just a natural consequence which makes the project go different than planned and put certain kinds of managers in distress)
- project start to get behind of the schedule or whatever tool in use to track progress
- "you are not a true Agilist"
I just can't understand why is it so easy to blame the old methods while it's so hard to identify weaknesses in the current ones.
Besides, the room they left for interpretation leads to a good amount of bike-shedding and witch hunting as soon as something goes wrong in the project -- if one assumes the method is perfect, the only possible explanation for a failure is that the method has been misfollowed.
Nothing in Agile has actually overcome the problems of horizontally scaling a team, and things like this stand in the way of scaling one vertically.
Individuals and interactions over processes and tools Working software over comprehensive documentation
Scaling developers vertically requires having support tools, processes, and people to get past the things that trip them up and back to forward progress. They don't have to be big tools, or big processes. In fact it's much more important that they be reliable than that they have huge feature sets.
But Agile without tools and processes? Show me anyone who is pulling that off, and I'll show you someone who has mislabeled a bunch of things as 'not-tool' and 'not-process'.
"That is, while there is value in the items on the right, we value the items on the left more."
Agile doesn't mean no documentation and no tools - it just means they should not be the focus.
The difference is one of intent. Having tools or processes to have processes is a bureaucratic mess which they Agile folks rightfully wanted to cut with a scythe. Sword. Scary sharp thing of your choice.
There's a difference between building tools and process, and building a culture of toolsmiths and process tweakers. The latter, I think, follows the spirit of Agile but not the letter of it. And lean is just... throw the baby out with the bathwater. It's bureaucracy as written by a minimalist.
Except for Jira, of course. /s
It’s so common that it’s been branded: SAFe, and it’s a complete abomination.
I strongly suggest that they accomplish this by using "sprints", because then it means that they only have to manage the communication before and after sprints instead of ongoing. I also have never seen my #3 really done well because getting developers to keep issues up to date has always been difficult.
Almost every team ends up doing daily stand ups, and when they don't it is usually because of timezone issues, so they find a substitute. This seems to be something that many engineers fall into as a habit to help keep each other unblocked.
The one thing that is problematic for my approach is predictability. If teams don't have an inherent value of completing sprint goals, then work carries over from sprint to sprint, and stakeholders can't predict when things are going to be delivered.
This is where CI/CD integration of tickets and good commit hygiene comes in, in my opinion. If your pipeline updates the state of the ticket as it progresses and commits are both sensible (describing the work completed rather than 'WIP: did stuff') and viewable from the ticket's history, that /should/ be sufficient to gauge progress when viewed alongside the work spec.
Daily standups: awesome, do them, if it works for you and your team. Don't let anyone fool you into doing something called one that isn't. Actually stand up (if you're able). Actually demand everyone (who's able) does too. The end of the discussion is when someone's uncomfortable. If that cuts the discussion too short, tailor future ones to accommodate them. Repeat until unnecessary.
Real agile (and real things that are actually used in agile) are not micromanageable, they're the antithesis. I highly recommend a read/refresher on the actual Agile Manifesto. All of the things described here that sound nasty are just what agile was challenging, in agile clothing.
Edit: oh how did I miss my favorite target?
Sprints: definitely not for me. They're the Trojan Horse that lets all the fake agile stuff in. I prefer Kanban, but whatever flexible, adaptive, communicative system your team chooses go for it.
There are many pitfalls. For example, giving product owner and even manager roles to the lead engineer or architect, daily standups devolving into telling people what ticket number they have in progress as opposed to blockers they are seeing or actually working on, product owners not showing up to backlog grooming sessions leaving engineering to make their own priorities, product managers being the engineering manager and leading retrospectives making everyone biased to say what went well but not things to improve on, agile release trains having teams that don't really interact with each other leaving engineering teams tuned out during system level PI planning and demos. The list goes on.
The current state of an org implementing agile/scrum can easily lead to what David Graeber calls Bull*hit jobs: https://www.youtube.com/watch?v=kikzjTfos0s. The onus is on the organization's leaders to take everyone to the desired state. However, all too often the actual leaders of an organization are the engineers themselves and would much rather get work done than to micromanage.
Agile the stuff people make you do in work is often pretty anti-thetical.
Scrum as a process is basically poison.
The agile manifesto is tiny and a scrum guide like this one: https://scrumguides.org/scrum-guide.html is readable in a couple of hours. But the version of "scrum" forced on many people is a far cry from that.
The one thing I've consistently seen absent in many Scrum attempts is the sprint retrospective. When this is included and is permitted to include not just code/product issues but also process issues, it has worked very well even when they skimped out on other elements of Scrum. But most often the retrospective is absent or the process is not permitted to be included in it. This makes you fundamentally anti-Agile as you literally have a rigid, static process.
The one consistent element that I have found across nearly every reading of Agile I've done and my experiences over the past (now almost 20 professional) years has been that the critical element of agile is its responsiveness and introspectiveness. Lacking those two things you do not have anything that can be called Agile, at best it's an imitation, at worst it's SAFe and you should run fast.
DevOps, Lean, Scrum, Theory of Constraints (realized in software, at least in part, as DevOps) to the extent that they have defined processes they are not the same. But the consistent element is introspection and responsiveness leading to adaptation to the team, organization, customers, and systems being developed/maintained.
This is the critical element missing from many organizations and teams at the time of the manifesto. See Waterfall, any CMMI office. They become static, they delay their feedback loops to extraordinary time frames. Waterfall (may it die a fiery death), in some spectacular failures I've witnessed, had 5 years from start to delivery for customer test, not deployment. CMMI has a strong association with Waterfall (unjust in my opinion), but it still promotes a static process that is only reviewed when it's time for your next appraisal (technically it promotes continuous monitoring and improvement, but like with Scrum everyone ignores it).
It's still a crucial element missing from many organizations who have cargo culted their way into Agile or adopted "Agile" processes (like SAFe, may it suffer the same fate as Waterfall). If your processors ever become truly static, you either found The One True Process (for your team and situation) or you're failing to recognize and adapt to your circumstances.
This is explicitly forbidden in Scrum. Retrospective is the only part that cannot be removed.
But I agree, most companies prefer to allow as little feedback as possible.
Most painpoints are external to our team anyways (otherwise it would have been fixed) so why discuss it sprint after sprint.
The good ones kinda resemble what the developers would tell each other if they had a beer together after work. They probably wouldn't press each other to "improve". Well, maybe they would, if there was one exceptional slacker. But even then, it probably wouldn't be like "work faster! faster! even faster!" but rather something like "run the unit tests on your machine before you commit the code, dummy, and stop using one-character names for variables, who is supposed to read that?". Which would optimally result in introducing policies to prevent that, such as running the tests automatically in continuous integration, adopting code standards and doing code reviews, etc.
A dysfunctional team won’t be fixed by a new process to follow. It’ll just warp to the dysfunctions.
Nowadays, because folks don’t like to work with older devs, I’m forced to work alone. Although this limits the scope of what I can do, it has allowed me free rein to formalize a manner of programming that has very good results.
I call it “Evolutionary Development”-. It requires a great deal of experience (not intelligence or education). Thankfully, that’s a resource I have in abundance.
You have not been satisfied with implementations you've experienced.
If I’m skating on thin ice; I might as well dance.
EDIT: It looks like you got dinged for that comment. I'm sorry. It was a bit challenging, but completely fair, done in a respectful manner, and I respect it. I expect and support that kind of challenge on HN.
Sprints and daily standups.
Daily standups are too often, not enough updates, and it feels more like pressure than utility for the engineers.
Sprints, while helping keep multiple teams working on a single "epic" or "feature" in sync, also feel like an arbitrary slice of time vs. letting people work on things at the pace they are comfortable at. Finish early? Careful taking new work in, it will look bad to bring new things into the sprint and not finish.
Take an extra day on a story due to some complications? That's fine if it's middle of sprint. But rollover into new sprint? Oh gosh, what will that do to our sprint report?
Time estimations, maintaining backlogs of work and prioritizing, and documenting work done are all great. But some of it has too much ritual to it.
yep. Furthermore, there are many other perverse incentives that I noticed, but one stands out: the incentive not to take on risky or difficult stories out of fear that if it is not finished by the "committed" date (end of sprint), you will be tarred and shamed during the sprint review.
If you've never worked in a Kanban environment, I highly suggest you research it and encourage your employer to experiment with it.
Scrum was really invented for situations where management is constantly asking "when do we get X?" and the development always says "we aren't done yet".
In this scenario, the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time, and forces the development team to put something out in a given time frame even if not yet perfect / finished / whatever.
If that's not a problem, Kanban can be indeed be a much better fit, and come with far less overhead.
I would rephrase it as "sprint is meant to make management to believe that they'll get at least something in a predictable time".
I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny.
Kanban still has estimates and you can still do bi-weekly demos of whatever has been done since last demo. Management can still get a sense of when they will get stories by judging how far down the backlog they are. Team is still protected from interruptions by their WIP-limit but PO can still swap out highest prio item not currently in progress, win-win.
I've even seen officially certified scrum masters using it in ways that go completely against the ideas that are behind it.
The main idea of Scrum is, to empower the entire team to decide on their own processes through finding consensus, and to get rid of annoyances that slow things down.
If Scrum itself becomes that annoyance that slows you down - then according to Scrum you absolutely need to get rid of it.
All the different parts of scrum should be considered an all-you-can-eat buffet. You are not supposed to eat all of it - you are supposed to just pick out the things you like the most.
The only core principle is to regularly meet up and discuss how to improve things. That cycle between two such discussions is typically called "sprint" - and that meetup where you discuss improvements is typically called "retrospective". Nothing else about scrum is a requirement. It's just a list of things that worked for some other teams - doesn't mean it will work for you.
From the perspective of Scrum this is incorrect. It is specifically stated that:
> Changing the core design or ideas of Scrum, leaving out elements, or not following the rules of Scrum, covers up problems and limits the benefits of Scrum, potentially even rendering it useless. 
Eg. If you don't follow the framework, you're not doing Scrum
I've read the book "Scrum: The Art of Doing Twice the Work in Half the Time" by Jeff Sutherland and J.J. Sutherland which goes into the history of how Scrum was invented, and the ideas and philosophy behind it - and neither that quote of yours, nor anything similar to it, is represented in that book.
I've also read "Essential Scrum" by Kenneth S. Rubin, which many consider the best book to read on Scrum, and that does not endorse anything like your quote either. That book definitely is more on the "all-you-can-eat buffet" side of things.
Both books clearly state in some form or other, that ALL processes cause overhead - and that does include the processes suggested/recommended by Scrum. And that's why you should always use as little processes as possible. Sadly you can't work without any processes at all - if you try that, some informal processes will just emerge on their own. It just doesn't work without - unless you are a tiny team of friends.
Scrum has become a big commercial enterprise, that wants to sell courses and trainings and scrum master certificates. They have a financial incentive to churn out rules to follow, because that's how they earn money. But that's surely not what is best for teams and work motivation. I really don't think that Scrum originally was about rules at all - it was (and should be) about what is best for teams and work motivation. Just my 2 cents.
The quote comes from the official Scrum guide. I'd say that is an authoritative source (just like yours, mind). I was just pointing out that according to 'the bible' you have to incorporate the framework as a whole, or not call what you're doing Scrum (Scrumbut perhaps?).
I agree with you on the commercialism surrounding Scrum and the financial incentive.
And yeah, I'll keep calling the old one just "Scrum", as it always was called, whether or not "the bible" allows me to :P
Management needs tools to detect (1) slippage, (2) true cost, (3) emerging issues.
Engineers need to not silo, work together, make progress, and share status.
Amazon would do it at 11am, and it would last no more than 10 minutes for a small team. Every two weeks, management and engineers get in a room to holistically determine where things are at, and then they go and report status up.
What I would tell teams that I bootstrap is that the process itself doesn't matter, but the team needs a shared discipline to be effective. Their team has desired outcomes and everyone needs to be accountable for making progress.
Then you check in as a group on a weekly, or maybe twice-weekly basis, with an explicit goal of identifying risks and uncertainties that have arisen during that timeframe.
The goal here is not to micromanage, but to give a sense of progress towards a goal - whether a metric shift, a release, a roadmap commitment, etc. If you don't hit your interval milestones a few intervals in a row, your high-level thinking about timing is wrong, and you need to adapt the project or the timing.
It's meant to help keep the team aligned on what everyone is doing at a higher level, not for any details at all. After the standup, the team can address any requests for help that came up as needed. But that falls outside of the standup.
Agile is meant to help empower teams and improve their velocity, and that requires people to own their own stuff. So the standup should be a purely informative, high-level overview of where the team is so everyone is aligned. If it's anything more, it will become a cumbersome, painful exercise in micro-management and tangential discussions.
Doesn't mean there isn't value to companies that have succeeded with it, or created a value culture around this coordination. But my experience was a bunch of people sitting around talking about what color paper should be used for a particular work item on the sticky board, which I struggle to see the value of.
In my mind scrum has less bureaucracy than that.
Scrum Meetings are best used as a way to come together as a team to work how to make progress today.
I want to deploy this change to prod today, but one of the tests is failing and I don't know why. Ok lets get a couple of people to mob on the test to figure out whats going on after scrum etc
That's a good scrum meeting.
Bad scrum meeting. Person 1: I did x yesterday. Person 2: I did x yesterday etc Person 3: I tried to get x done yesterday, but I got stuck i'll try again today.
No value whatsoever.
The emphasis should be on problem solving as a team, and focusing the team on pain points to get work across the finish line.
To that end i find "walking the board" far more valuable, than status updates from each memeber.
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
Agile is one of those things that seems like a dream for micromanagers, and if the extent of your company's Agile implementation is saying that you "do Agile" then yeah it's going to be a nightmare. But Agile teams are supposed to be largely self-organized and self-managing. I don't want to No True Scotsman this but if you're doing Agile right there's very little room for some external micromanager to impose their will upon you, but there's certainly room for one to crop up internally.
An old coworker used to say that Agile was created by someone who was sexually attracted to meetings. We don't do a lot of them, or we do them with a subset (on our team of ~11 including the manager and analysts, backlog grooming is 2-3 people for example).
What is the minimum number of weekends that are needed to earn that?
Without moving any goalposts, still less than one, correct?
Not meaning to single you out, just curious since you would be in a position to know.
Kudos for letting it expire.
Not that I don’t like agile or scrum, just the certification thing kind of gets in my craw since it’s so little effort and used as if it’s a big deal.
Correctly pointed out! I have come to dismiss these folks out of hand without losing anything.
I bet they made a ton of money from it.
Regardless, several techniques are actually worthwhile: Retrospectives for things that happen regularly (they aren't useful for things that happen very seldom). Daily standup as a sync for developers that collaborate the same task.
Estimation? It's about communication. Standups? Communication. Grooming? It's communication. Retrospectives? Communication.
All the bits are intended to foster communicating different issues that ought to be discussed.
What works for my teams in the past was to just pick a process then regularly ask ourselves if it’s slowing us down or is missing something, and change it slightly when necessary. You may need a few weeks to get used to a working routine that works for everyone, and it’s likely that will evolve over time depending on the people and projects. Better to keep processes to a minimum and make it easy to change it in cases something doesn’t work.
I like the process based aproach of PMBOK, which is a set of processes that can be applied or left out, deoending on the project context.
Unfortunately I see a lot of Scrum managers, and certified project managers constantly applying all processes they learned about and furthermore annoying those who do the actual work.
Dailies are the most stupid invention ever. Even if its just 15 minutes, its either blocks your "agilitiy" if its on a time-slot that you prefer not to work, or it steals almost an hour because you get out of the tunnel, wait for the meeting, have to get into working mode again.
Standups are good for small teams all working on the same thing, and only if no managers are present. Unless the manager is writing code too .
Kanban seems ok but i havent used it for any period of time.
The various tools are nice for remembering what needs to be done and making shared checklists.
This is the crux of the nonsense. A high-level engineer can work around this but for the mass of ticket punchers, it just encourages non-thinking, risk aversion, and a lack of trust between themselves do the pressure of velocity charts, which translates into buggy code, mounting legacy blockers.
I know frontend engineers who didn't know what a finite state machine was, nevermind how it was implicit in their business code. For the mass of mediocre engineeers, sprints kill incentive to learn and become a better engineer; no is rewarding you.
Product doesn't care cause they're incentive structure is advesarial to Engineering push-back on tech debt, refactoring, etc. Sprints allow them to make sure their bonus is on time. Then Product people quit when BS mounts, another round of Product management shows up, and rinse, repeat.
I've seen this cycle happen three times in one org in just 5 years, the org where I started as a Junior.
And don't let DevOps also be working against sprints in a mediocre org
Sprints have, for most of the industry, not the Top 10% employers and what not, frankly regressed the industry.
Everyone stops working for the organization and starts trying to figure out how to make the organization work for them, from engineering to product to devops, etc. Good hiring is also a factor in what you'll get out of your employers, but sprints don't get you more at either rate.
Sprints are just time-bounded units to plan and execute the work with the stated aim of having working software at the end of each sprint. You can do that indefinitely in the same way you can follow another software development methodology indefinitely.
I agree with this statement. However, I believe the term is poorly chosen and, in my experience with managers, frequently misunderstood.
There are two issues I have with the term. First, sprints, as a physical activity, are about short, very hard, bursts of work which are fundamentally unsustainable. Even an athlete competing in sprints takes a good break between each one. Second, "sprint" conveys a sense that the focus is on speed because that's how we judge sprinters.
The first point suggests that Scrum needs a different kind of interval than just a sprint. It needs something like a rest period. Not a "sit down and do nothing" period, but analogous to the "active recovery" that athletes often take part in between exertions. Something productive, supportive, but secondary to the principle objective (a runner isn't at the race to stretch, but they stretch so they can continue to race).
That second point is important, managers hear sprint and they think speed. Any kind of slow down or delay makes them think that the team is just dicking around. The idea that a sprint could be spent on anything bringing indirect value (rather than direct) like test and deployment automation, refactoring and cleanup, or training is antithetical to this perception. Consequently you cannot, easily, put those activities into sprints, or you have to disguise them or mete them out over a series of sprints so that enough "real" value is being created from the management perspective.
Finally, "agile" is about responsiveness. The term was chosen for the manifesto deliberately. We don't look at Usain Bolt on race day and say, "Wow, that man is agile". But you would talk about the agility of a football player who loses speed dodging, avoiding, and leaping around a field to get a 100 yard touchdown. The agile player is responsive to opposition and present conditions. They do need to be fast, but their ultimate speed isn't just from raw speed but from their ability to maintain progress despite adverse conditions. A faster but less agile player could get lucky, but more often will get blocked. The use of the term "sprint" in Scrum conveys no real sense that adaptation and responsiveness are important.
This is exactly what I meant by calling them nonsense. Calling them rounds or periods would have made much more sense. Especially since a coding sprint was already a thing, and meant lets ignore everything else and just write code for a few days.
I've seen people become more interested in what I call "Jira ticket engineering" than the actual work.
We use Rally, but I have seen the same thing. There is hope among some that switching to Jira will solve that problem.
So why is Scrum so prominent in the software industry today? My guess it that, although bad, Scrum is not bad enough to actually completely destroy the productive of a team. Developers are still able to produce output despite the process. OTOH, mid-level managers are able to use Scrum to produce numbers/metrics to make the upper level happy, get promoted, move onto other companies, and make Scrum spread.
Is my view somewhat accurate? Is there anything we as developers can do to help improve our work environment? In the end, are we powerless against the wrath of the management?
The "Agile Manifesto" is just well known platitudes.
Agile!: The Good, the Hype and the Ugly by Bertrand Meyer is a must read.
If you don't care about delivering broken software and having high engineer turnover, scrum is just fine.
And don't get me wrong: customer needs are the priority in every company that sells software or provides SW services. But one thing is what customer needs, and another is how to provide it to them.
More times than not, in those places, we ended up redesigning a feature in the middle of the development because it was designed by POs and other ilk only looking at customer needs, so that design didn't fit the system.
Yet if you look at the original scriptures, you don't find any ceremonies, just a message, and it's more like a guideline than a rule.
I like the message, but I don't like religious enforcement of the ceremonies. Some work, some don't. It depends on your team.
As an example, I have never had a PM/Team practice Agile/Scrum in a manner where the total amount of Work-in-Progress is something that gets paid attention to.
In my opinion this is a very serious error.
In those areas, I think that simply following the Scrum ritual is not necessarily harmful, however it is almost surely _not enough_. At least one person needs to have read through the scattered stories, built a mental model of the project's function, and have enough experience to start forming a notion of how things will work given the resources available. Better yet, if everyone has done that and can collaborate on a sketch of the architecture. Without this, all of the points poker is just Ouija board voodoo for the non-tech stake holders because nobody could possibly know how much effort it will be to build that 'Implement a button to do-complicated-reporting-process' down in the backlog.
However, I have witnessed several teams where conversation around architecture and data model simply doesn't happen. On sprint one, everyone gets some stories, and goes off to do their thing. What you get is a minimally-coherent-to-satisfy-the-story data model and massive duplication of effort and code.
That problem should be taken care of with story grooming and the regular, deliberate, refactoring and tech-debt pay down but I don't see that happen very often in practice. Everyone is in too much of a hurry to stop and say 'wait, this code is demonstrably garbage and we're doing it wrong'. They just build around the weird, wrong, or inefficient parts and get their stories finished.
If I think the level of process and granularity is overbearing I say "no thanks" and pull the "Individuals and interactions over process and tools". If there is one thing that I wish I would have learned earlier in my career is that it's really ok to say "no thanks".
Can the team decide they don't need dedicated standups, and stop doing them until they decide they want them again?
If not—if management mandates them, if some single in-charge person (who may or may not also do some programming on the team) would, all on their own, be able to veto that change even if every single other person didn't want them, and even if offered alternatives to suit whatever needs they actually have, or if you'd feel uncomfortable even bringing it up even after you're pretty familiar with everyone there, or if you're not even sure when such a discussion might occur ("pretty much any time" is the best answer, but "during a retro, and only then" is... OK) then very probably the agile you're in is bad.
If that's something that could, plausibly, happen, then there's a decent chance it's the good kind.
One way to get a sense of this if you're new (even during an interview) at a place that actually claims to "do agile" and has done it for any length of time, would be to ask what they've changed about their process since starting. "Nothing", especially if accompanied by seeming baffled by the question, is such a bad sign I'm tempted to name it as sufficient evidence per se for a "run far away, very fast" reaction. Citing deliberate abandonment of or modification to any major agile "ritual", arrived at only after initially trying it the normal way and not just because some manager said to change it, but because the team wanted to, is a very good sign, though just because they haven't done that isn't necessarily bad. The point is: is agile a straight-jacket for the team, or just another tool to use as they like.
There are lots of other bad signs one might see (multiple teams in a standup, standups becoming perform-for-the-manager prove-you-did-work describe-every-little-detail-of-your-"struggles" garbage-micro-management-meetings ruining every single work-day, et c.) but that's an easy one that can be checked for even in the absence of other obvious problems.
In my experience only one company of the six I worked for was doing real Agile. Really short stories, the entire team (inclusing devs) talking to the customer, meetings reduced to a minimum, xp practices all over the place. High value produced, happy customers.
What I noticed about it was that: - every single member of the team believed in it, so no protests - management believed in IT and paid for both agile and xp coaches - hiring was being done right, hr on the first call already clarified what we expected so zero false positives in the hiring phase, new hirings didn't need convincing - slow hiring. The majority of devs hates agile, scrum, pair programming, testing and talking to customers
I left after 5 years to try something new, I still don't find something as good as what I described above.
I then worked for both startups and corp but when they do it, they do it wrong: focused on the process and not on the outcome. People were told "scrum is mandatory because we are doing the digital transformation" or whatever. No measures of the outcome.
Anyway, I firmly believe in Agile, I saw it working in a product company that made billions.
Unfortunately the movement got polluted with consultants that need to sell their service so I personally think you need to get lucky to find a proper place to do it.
Agile at its core is about a few things: committing as a team to work (shared accountability), creating reasonable expectations of what can actually be delivered (as opposed to how much the boss wants to get done), creating a cadence of delivery that is aligned with value to the business, and continuous improvement (through metrics and retros). It’s not perfect, but an agile process run well creates consistency, which over the long run is very important.
Scrum is a way to force communication, create awareness, and adjust prioritization. A lot of people think this is a waste of time, but a high performing team requires excellent communication and this is one way to achieve that. If your team is not getting value out of it, that might mean people are too silo’d.
Having said all this, it’s all about how the team works together. These processes are meant to focus a team on delivering business value. If a team uses another process and performs well, there’s no reason to be dogmatic.
This is the problem: that sentence is backwards, as it is scrum. A high performance team HAVE excellent communication. So Scrum tries to force this hoping it will create a high performance team. Effect before the cause. Maybe if you are lucky, it would work... maybe.
From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities.
From the team/developer's POV, I personally feel like it gives me more freedom (I get to choose the tasks I want to work on, obviously in the limit of the sprint backlog) and a good ratio between work variety (I have the opportunity to work on something different every 2 weeks) and work stability/visibility (once the sprint planning is done, the sprint backlog normally won't change for 2 weeks).
> what are the pros and cons of daily standups
Ensure that everyone in the team is on the same boat. Encourage communication between developers<->developers and developers<->product manager.
I often read on HN that daily standups is micromanagement, but I've never felt it that way (in 10 years of doing agile/scrum in different companies, from the developer's POV as well as from the manager's POV). I guess it can vary from company to company and team to team tho.
> From the company's POV, being able to change the development priorities every 2 weeks based on the new business priorities.
Or rather, from the team's PoV — to NOT change priorities for 2 weeks, to not have side channel communications, or random diversions from email or chats, and being able to focus for 2 weeks without getting carried away.
I've been in too many companies with an "inverted" org structure, dozens of managers trying to push stuff into a lone programmer (inverted pyramid). Being able to lock down the backlog, focus for 2 weeks, close the door on background requests (perfect reason "we're in the middle of the sprint"), and leave those managers to fight between themselves in the background on how to prioritize the next 2 weeks — it's a good thing.
This part always interests me because I've never worked on a team where it actually worked that way, or even made sense to work that way. You get a few people together, a cryptography expert, somebody who knows eMMC really well, everybody kinda knows USB, and one person with much stronger EE skills. And I do go fix a simple bug in the eMMC stack, but for new features its like, well this will take me 10x longer because I'll have to read some long spec. I have no relationship with the hardware folks who I might need to collaborate with. And during this time I guess the EE is having fun, but out of their element implementing Elliptic curve cryptography while the crypto person sits on their hands because they're only still on the team on the assurance that they'd never have to touch their hated SATA driver again?
It's not that I don't believe it works, I just wonder how it would work for me.
That's also the reason they advocate that ideally the team should sit all together. In that ideal work the daily stand-up lasts only 5-10 minutes, it's not meant to be a dreaded status meeting where you talk for 5 minutes then try not to fall sleep for an hour...
Daily Standups are supposed to be Daily Planning Sessions for the Team. But the common implementation has devolved into status update meetings.
So the con is that, more likely than not, it will be a status update meeting, in which case, a waste of most people's time.
If it's a Daily Planning Session, there are no cons, only pros.
The pro is team alignment, with each other and with project objectives and goals, with only a maximum of 24 hours for possible misalignment.
Misalignment is ALWAYS the problem. Daily Planning Sessions help mitigate that ineveitability.
I.e. a popular set of productivity tools with a cottage industry of people trying to teach it behind it.
If you look at it as a set of tools, you can make something really tailor-made for your team and on occasion it lead to creating a truly bespoe process that fits our team needs and doesn't have anything to do with scrum anymore :-)
With things like standups, backlog refinements, storypoint estimation, based on my experience this works for team of 3 to 10 people, with a clear responsibility that work together on a project for at least 6 sprints (usually 2 weeks/sprint), where new work can wait for new sprint to start.
It helped us focus, storypoints started to work for estimating stuff after ~3 sprints, our managers got used to "no, we won't start working on it right away, put it in the backlog, you will join for prioritization anyway".
Holding all else constant I hope to have a job where I am not on the spot for making some unknown amount of tangible progress every 24 hrs. Deep work cannot take place in short, consistent staccato steps. Sometimes big moves forward happen in a day. More often it’s a day better spent thinking hard, rather than thrashing around for quick answers.
Moreover, if I have to ask for extra help to make progress quickly and consistently, I miss out on the learning that trying things myself would provide.
In addition to being very unfulfilling, this means that I do not grow to properly understand the codebase in a timely fashion. This means I will under achieve over the long haul. All the better to judge me inferior I suppose. It can be quite toxic.
You say Agile disrupts your "flow", makes you deliver buggy code and just work to close tickets like a drone?
Good! Who said code needs to be perfect and bug-free? remember Lean? Just get it out there! we can always fix things later.
From a business perspective - we are spending money to develop functionality, not our peoples skills. Tickets and tasks should result in adding value to the business, not to our codebase.
This is a cruel and unsustainable way of thinking, which will have your best developers leaving the company very quickly. But if you're an enterprise corp - you see them as interchangable "resources" anyway, and Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This is also a way of looking at things...
I mean, they should but its not always a direct path. Resolving tech debt should speed up delivery of future products and features. Do businesses actually understand that reasoning... not really from my experience. This is really just a lack of understanding or appreciation of nuance for how software is developed by non tech companies that have been forced to hire engineers and create engineering departments.
> Agile helps you accomodate to them leaving by splitting the work to small bits and having no single owner.
This only holds true if you have a team structure and organization that prevents specialists and keeps everyone as a generalist. I don't believe that's actually possible...
Instiutional knowledge is massive, and I feel its often vastly undervalued by companies when engineers decide to leave.
Scrum is incompatible with Agile principles.
Regarding Waterfall, it's not a strawman. I've witnessed many Waterfall projects over the years at my offices. Two of the most spectacular were planned on the order of 5 years, one failing spectacular, the other only "succeeding" because the follow-on project was started 2 years into it and still had 2 years remaining, so they deployed the completed one.
They really did follow the moronic linear flow Royce said doesn't work (at scale). The spectacular failure was billions of dollars worth of work wasted as it turned out they didn't build what was needed. Another project was started to replace it before they even finished testing and deployment.
It has backfired, because most organizations cherrypick what they want about Agile, and discard what doesn't adjust to the "way we do things here".
In case this resonates with someone, I wrote more about it here: https://alvaroduran.com/essays/against-agile/
Like others said above, Scrum did reduced the time we between when we finish a feature and when it hits production. I like the idea of quick feedback cycle and fast iteration.
But most companies abuse scrum and see sprints as a way to squeeze more out of dev teams. I've been working in a scrum team (leading the tech team as a tech lead, not product owner) for 3 years and I'm burned out now. Trying to get to a different place soon enough.
It is good for the product/managers, but for dev teams it can be bad if not done well.
However, I spent some time working with contractors at Pivotal and I met an EM at one employer, and these people seem to take this stuff super seriously and get good results. The difference is that they do not just have standups and backlog grooming and retrospective. They do EXTREME PROGRAMMING. I am not sure if this is suitable for all kinds of work, but it was highly productive in my experience.
In that case though, the answer to your question is still "no," because there is no extra bureaucracy and because the points exist to serve the team rather than management.
Being able to throw all of that in the bin and just say "we're Agile, so it'll be ready when we all agree it's ready, and we'll direct effort where we think it's most needed as we go" is awesome.
I've never worked with Scrum, but I have solid negative opinions on it (so hopefully I never have to). One of the core parts of the Agile Manifesto is "people before process" and Scrum is all process, so I'm always confused as to how the two became synonymous.
* Sprints - Instill a sense of urgency - Reduce scope to a manageable set - Allow for short-term planning and reflection (and short term is the only term that works) - Align the team
* Daily Standups - Provide a relatively cheap and high-bandwidth way to disseminate information. - Keep the team bonded and allow for early course corrections.
But the books is full of gems, so my two sentence overview doesn't do it justice. Read it here https://basecamp.com/shapeup
With that said, I don't expect any manager to allow us to try out. People love that they can hear people every day that they are all very busy.
My current Scrum experience is from a large retail company. Our mobile app team of ~8 devs tries to keep up with the web team of ~50 devs (or even more, I just started and we work remote, I have no clue about the exact numbers).
The schedule, roadmap is mapped out for at least the next year.
Then, the Scrum doesn't make any sense. We can't decide what's important for the user. We can't work on bugs (that makes the lives of our users miserable) because we work on big feature launch X, and if we don't finish, it will jeopardize big migration Y in 2 months, and then it'll make big relaunch in Country Z impossible in 4 months.
It's waterfall with two-week crunch times and daily standups. And our ratings in the app store are constantly declining. But hey, at least we are on time, no matter how terrible our app is, in Jira it says it's shipped so don't whine about software and product quality.
During my whole career (about 5-ish years), I didn't find a place where a standup every day made sense. I think two or three sync-sessions per week would be perfect. Daily standups just made anxious, nobody listens to the others, you either say too little or too much, and the original promise of standups just didn't match my every day experience: we never found blockers we wouldn't have found otherwise, etc... In my opinion, pair/group programming (2-3 ppl) is thousand times better.
Whether people say it is good or bad, it is useful to understand the context, scale and criticalilty where they came to that conclusion. Otherwise it is very difficult to compare answers.
I also don't like points generally. To some degree you need some kind of estimate, but estimations are notoriously inaccurate, so just embrace that and stick a "days/weeks/months" label on something and call it a day (though if it is weeks or months, it should probably be broken down, but I do that on-the-fly as I arrive at those bigger tasks and develop an understanding of what's involved).
I actually do find standups useful in my experience, because in my team we have a couple individual contributors working largely independently on independent components of an overall software suite. Some of them are new and so might try reinventing wheels we've already solved in other compartments. By having a dedicated time for people to just talk about what they're doing, more senior developers can catch when wheel-invention is happening and steer the more junior developers towards existing solutions.
But above all, don't cargo-cult any practice. Find what works for a specific team and run with it, because different teams have different needs. That's the real essence of Agile.
And then I've seen it fall apart, in the exact same place, because upper management wasn't getting progress reports in terms they understood.
It can work, and work well. But it's far less automatic than people think, and far more likely to turn into cargo cult agile.
So instead of, on hand, having constant daily storm of thing, or, on the other hand, having tasks that take forever and never end, you have time-boxed 2 weeks sprints that you plan beforehand and do them. It's not overly planned for the next year, it's also not no planning, it's "just right". Management is happy that they see what is going on, developers are happy that they are not micromanaged.
Daily meetup is just to check up how things are going. It's good, but it needs to be really checked by someone to not exceed some time and not be yet-another 1 hour meeting.
All the other things can be safely ignored; all those managers and owners and masters, they would exist with or without scrum and they effectively don't matter all that much.
What I do hate is "story points" and "velocity", because they at the same time don't mean anything and do mean something. In my head I convert them to "mandays". I don't know why people don't call them "mandays". "But they are not mandays" you say... well they mostly are, let's call them that.
I never had experience with all the other weird rituals like the cards.
1. I get to see the progress of the project as a whole on a daily basis. Without the stand ups, I probably would have no idea how and what we are doing as a team and I'll just be doing my own thing.
2. There were times I mentioned an issue I ran into and others chipped in with helpful ideas (sometimes even the solution) saving me time. If it weren't for the stand up, I would have just solved it on my own anyway but could have taken more time. In a way, this opens up a helpline.
3. If you are a team lead, this can help make things more predictable. There's an understanding what everyone is expected to do in a regular meeting than scheduling meetings when you think is needed but others may not have the same motivation for a meeting and can end up same few people talking every time.
I hate meetings in general, but I hate surprises even more. So, seeing meetings pop up suddenly on my calendar is something I really dislike. Agile and the stand ups at least make things predictable like short 20 minute meetings every day. After I get through that, I know I'm not gonna be bothered again for the day :)
Helps to avoid continuous changing direction at request of stakeholders. 2 week sprint feel really good as planning horizon: not too long, not too short. Teams do not commit to anything beyond that timeline. Any roadmap commitments are based on stats and product owner responsibility. Team is not accountable for any missed deadlines.
It can feel like wash-rinse-repeat sometimes. Can be a killer for flow and feel inflexible when you are nearly there (getting it done) and the sprint review interrupts the flow. If the balance is bad you should probably look at kanban.
Excellent way to find out if team members need help or some syncing is needed. If done well team will “feel” if your getting closer to getting everything done. With work from home good to see everyone on the team at least once a day.
Hard to get right. Should be about inspection by the team to help adapt the plan and get to your goal, but this is often forgotten. Might become a way to “control” the team and put pressure on people and check for performance of individuals.
As for micromanagement: this is not exclusively found in agile / scrum. A micromanager will find a way to abuse any method to “control” their world. If you let go, set a clear purpose and direction, start helping team members to get more autonomous you will find that performance goes beyond what micromanagement can achieve.
Scrum (as defined in the scrum guide) can work, when it doesn’t: adapt and try again.
Agile works best in environments where the scope or execution methodology can not be discerned up-front or where it is crucial you need assurance that expectations are aligned. Your risk profile is much higher due to the number of unknowns, so a lot of time is spent doing work "around" the design and delivery of said thing to mitigate all that risk. As such, it works well for mostly corporeal endeavors such as building new software, or things that . This helps operationalize a feedback loop of try, test, re-align, try, test... etc. across stakeholder groups to help make small rapid course corrections until you get to where you need to go or abandon at an optimum time without marching like lemmings to a cliff.
It also works well in technical environments where there is a lot of collaboration and interfacing between different specialized groups. Forcing everyone to come together and be accountable for their dependencies to each other reduces those instances where blockers, compounding delays and finger pointing send things off the rails.
Estimating, assigning, controlling and monitoring, what you would typically term "earned value", in a project management sense is extremely difficult for these types of things. If the scale of work is large things naturally land on amounts that aggregate up to something useful
The two things I often see in agile projects/organizations that are often done poorly and lead to failure are:
- Maintaining a proper understanding and separation of the delivery risk (risk associated with building, creating) and the delivered risk (the risk you've baked into the "thing" by aspects of its design)
- Not allowing for or tracking risk mitigation, or how residual risk is trending
- Thinking because every project is unique that they are unique and therefore need a unique way of managing the project (i.e. re-inventing basic project management methods)
- Thinking your business is unique (it's not, less than 10% at most) and that therefore everything you do, including how you execute projects is unique (you don't).
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
And in his book Clean Agile: Back to basics.
Agile is for quick feedback on made progress, to compare it to expected progress and to be able to report your progress and forecast to business people to let them know how far behind the schedule you are as quickly as possible.
Let's say it's January and you need to deliver a product with a 200 use cases on July. After just a few first iterations you will be able to tell if you can deliver all use cases on July or quickly give feedback to business people that you won't be able to. From there you have options: close the project and stop investing time and money in it, add people to the project because you got your info very quickly that you won't be able to make the deadline in 6 months.
Uncle Bob talks about it in depth in one of his lectures here:
And in his book Clean Agile: Back to basics.
Agile is defined here: http://agilemanifesto.org/
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
And it also contributes to this one:
"The best architectures, requirements, and designs emerge from self-organizing teams."
That statement indicates just how broken the whole idea of "Agile" is.
It also sounds like there is not very much trust between team members. You immediately go to 'signalling progress vs. actually making progress'.... The scrum ceremonies are actually meant to support an environment where developers trust each other and one developer helps another when s/he could use it.
Editing to add: learning is an important part of being a programmer. Experimenting, reading the manual, trying it out, these are all things that get managed out, when you have to beg for "spike" time to do them, and somebody else doesn't see the importance.
The upsides are that it does make it somewhat easier to pivot or to shelve-and-resume when you know which of the bitty pieces are still to do, and it makes long term estimates slightly less arbitrary.
So. If you're not doing scrum you are not leveraging it's potential and even more important, its rules.
The rules of a daily is non-disputable. It has a formula. If you're not following the formula, it's not scrum.
A daily is not about progress. It's about communication. You communicate what you did since the last daily, and what you expect to do before the next.
But you're not being measured on what you communicated. You are merely sharing what you' re doing.
If there is discussion in a daily, it's not a daily. If you're not using a board for the baseline for communicating, you're fucked.
The role of a scrum master is to take note of what is going on and help out if she hears anything that sounds off. A good scrum master is a bit like a dictator. Focused, on top of things, helpful and listens to what is going on and does not bend to outsiders.
Good scrum masters are hard to come by. That's most often imo, why scrum had a bad rep in some places.
Also remember, agile is something that must happen on a top level, otherwise it will not work very well.
This is never true. Its a daily confession of what you did. Its micromanagement.
Agile gives you principles as to how to envision developing software. Scrum is just one implementation that tries to follow these principles.
I'm not a fan of Scrum, although I can understand why some of its components could be attractive. Velocity for example is interesting, as it's an attempt to empirically measure how "fast" a team can develop, and base estimations on that instead of just throwing a bunch of hours/days as an estimate when in fact it's hard to do that. I still think it doesn't work well to solve this, but to be fair I don't think there's a single method that solves it.
In the end, I think Agile is beneficial (in my experience!) but more importantly that you need to use and tailor a software development methods to your own needs and context, and stop blindly following existing models but instead see them just as what they are: tools.
As another example since you mentioned it: daily standups can be good, or terrible, it depends what you make of these. I've worked in a company where it was basically a "scheduled waste of time", but I moved to a place where we mixed it with basically a "hey good morning" type of coffee break and it worked rather well in a casual way, chatting up what was coming and that's it. And we keep in mind that if some kind of "ritual" becomes useless, then we skip it altogether as soon as we agree there's no value in it.
That last part feels important to me because that's ultimately where a key aspect lie: when you say it's a "micromanagers' dream", I think it just shows that the software development method can always be twisted and hijacked by some people given enough power/representation/influence.
There are two massive red flags in that sentence. If the standup is being used as an excuse to micromanage something has gone horribly wrong. And if people don't use it to make progress (that is, asking for help and mentioning blockers) something else has gone terribly wrong.
> Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
There are about a million discussions about how broken Agile is, most of which discuss some abomination of a process with very superficial similarities to Agile. It's not like having a standup is some sort of magically good thing on its own if people just use it to do things the way they've always done them.
Cue the inevitable "If everybody is doing Agile wrong, maybe there's something wrong with Agile?" response, to which I would simply say that I've seen Agile work in at least two completely different workplaces, and I've seen how terrible non-Agile processes are in at least another two.
Far better in my experience to spend time analysing the requirements as a whole, to distil the essence of what's being developed, and design a set of components that express that essential nature in a flexible way, such that the features arise out of the combination of those components rather than being developed in isolation and then mashed together as the project progresses. Accept as a given that intial requirements are just a best guess, and design accordingly - to cram piles of poorly-thought-through code through reams of unit tests is to fight this reality, not to embrace it (note that this is not to rag on unit testing itself, which, like any good tool, is extremely useful when deployed appropriately).
Doing this kind of analysis up front and then developing the components using scrum - that would probably be OK, but I've yet to see or hear of anyone doing that.
As for the process side of scrum: stand-ups are fine if they are kept very short and simply used to express and work through problems, but this appears to require active policing to prevent people rambling, and the retrospectives again are potentially useful, but in my experience turn into long awkward sessions of scratching around to find items for the 'things that went well/went wrong/would change' lists - and more often than not 'things that went well' could be summed up as "we all did our jobs". Celebrate genuinely awesome results, sure, but as a software developer, I don't need or want a pat on the back just for developing software successfully. Overall I would say that the principles of scrum sound nice but when they meet real people the results are somewhere between mediocre and painful.
Agile has a number of assumptions regarding organizational culture and the people involved on the project. Those assumptions are usually not discussed very often, which is bad, since I believe they are typically related to those many cases of failed Agile implementations that end up getting different explanations depending on how one likes/dislikes Agile.
To summarize what I'd like to answer about your question:
- They are great tools to break larger projects into smaller chunks and to keep track of their progresses. Experience shows that it's easier to reach success on smaller projects, and sprints and daily meetings are ways of emulate such sort of project even when working on larger ones.
- There's an opportunity of catching and fixing schedule slippages, requirements misunderstandings and other sorts of deviations before they get too expensive to fix.
- You need a bigger deal of maturity and commitment of people involved. As IT professionals, we usually complain about users being unprepared for working on Agile projects, but we have to admit that many professionals show a significant decrease in performance when they are not under a certain level of healthy pressure.
- When you favor people over processes and communication over documentation, a higher level of mutual trust is required. You can't find that everywhere, for a number of reasons. Some say that such organizations are not prepared to work under Agile rules. Some are more pragmatic and adapt. I stick with the latter. Agile talks a great deal about embracing change on requirements, and I don't see what is the point of being a purist and refusing to adapt the method to deal with risks.
In that sense scrum is like "training wheels for self organizing teams". Once you understand the benefits, a small team should be capable of modifying the system.
If we look at productized processes Kanban is much better at getting the essential framework in place.
Scrum is not the worst process that could be applied to software production for large orgs. Worse examples include for example a no-process, hardware companies shoehorning software development into hardware development framework and so on.
IMO as a junior dev over a decade ago it was nice to have scrum when I started at a company since that framework made it very explicit what the rules of the process were. A no-process would have been much worse and stressful.
But high performing teams tend to realize there is no one shoe fits all solutions to complex processes and then evolve their own system.
The pro of having a sprint is that the team knows what they can do in advance. I don't need to ask my boss for a new task, I just pick the topmost of the board that's not been worked on. The con is sometimes added pressure to finish a sprint (beyond normal pressure and without real-world cause) and a lot of time wasted in team wide meetings to plan a new sprint.
'refinement' meetings as far as I understand are unfortunately usually a waste of time.
Estimations in terms of 'effort' points are a recipe for failure because ultimately they will be converted into man-hour units yet were not supposed to think of them as time but 'complexity'. As a result velocity and burn down tools are just a cause for strife. I'd recommend using a normal time unit instead. Skip the conversion.
The other way these things can possibly be made useful is if the most important metric is not velocity but reliability (which most teams don't use but is used in at least one team in my org).
Retrospectives have the potential to be a cause of strife for obvious reasons. Usually they are pointless because people understand it's a powder keg so you never learn anything.
Personally I don't like agile/scrum but if I'd have to do it myself I would keep at least some elements, like the board you can take tasks from. Standups I would like to see alternatives for. Estimations I would try to do myself or maybe have a tech lead do. I wouldn't even bother communicating it with the rest. Ultimately I never learned anything besides agile scrum so I'd have to adopt at least parts of it no matter that I dislike it.
Anyone familiar with Japanese business/engineering process knows that the principal engineering project management fuel is meetings. Highly organized and structured meetings. Our headquarters building in Shinagawa had two entire floors, dedicated to conference rooms, and every floor had at least 4 conference rooms, along with "ad hoc" conference rooms, made up of file cabinets, set up like a grade-schooler's home "fort."
We had to book conference rooms six months in advance, for a half-hour meeting. Once, we were ten minutes late for a meeting, and the booking system automatically knocked us out, and assigned our room to another team. We went out to the coffee shop, but couldn't "talk shop" outside the headquarters building.
Yeah...they take meetings seriously over there.
So my team (based in the US, but run from Japan) hired a really sharp guy to be our process/infrastructure person. He was loved and valued throughout his six-year tenure, and we cried for years, after he moved on to greener pastures (this story might illustrate the appeal of said "greener pastures"). He was a fairly new Agile proponent, and proposed a daily standup.
So, anyway, the spirit of a daily standup, is to be informal and fast. Start of day, 15 minutes, no chairs, lightning talks, very brief Q&A, What I did, What I Want to Do, the Challenges I Anticipate, etc.
So, our Japanese liaison member (the person responsible for learning our process and representing Tokyo's interests to us) takes a liking to these, because...meeting GOOD. You get the picture.
So our "standups" ended up becoming hour-long daily pre-lunchtime events, with a booked conference room, seats, a fixed agenda, and a daily report to Tokyo.
Be careful what you wish for.
Having said that, I've seen a lot of agile projects fail, because people are too busy worrying about being "agile", while forgetting to apply common sense.
The place I work at is doing it wrong in my opinion: sprint points are directly mapped to time (instead of complexity), meaning that each day = 2 points per developer. Stand ups are really just status updates to our product manager - developers don't actually chat to each other about issues, we just report to the pm. If the pm is in another meeting, then standup doesn't occur at all.
The worst thing about it: There is no end in sight. There is no natural endpoint. It's just ticket after ticket after ticket, with the almighty burn down chart looking down on us. It just never ends. In a way we are assembly line workers. We cannot take slightly longer than what the ticket says, then you are forced to explain where you are stuck, even if you aren't stuck, so people thumb suck reasons.
(With something like carpentry, you build something, apply finishes, enjoy the product, AND IT IS DONE. With software development + scrum = infinite treadmill. You get deprived of ever getting a sense of accomplishment.)
During sprint planning we also assign the ticket upfront to specific people, so we have hectic issues with knowledge silo's.
On the sprint point side, we basically either have tickets that are 3, 5 or 8 and nobody dare picks another number. Using their system of 2 points = 1 developer day, some tickets should be 20 points, simply because it will take the person at least the whole 2 weeks to do. Some tasks are inherently complex or tedious and will take longer, but at this company we basically have to rush everything. Nobody ever has downtime and time to think.
I'm kind of over the company and over scrum. Looking back after 10 years, the only place where scrum did work for me was at one company (that sadly closed down (infighting between directors)) where we didn't take it serious at all - it was all for fun, no drama/seriousness, no care about mapping points to time, retro's was super funny (and not a moan fest) - basically nobody took it seriously and our productivity was crazy good.
Another place I briefly worked used old school Gantt charts which worked surprisingly well even though I didn't like it in the beginning (it was a more waterfall-like approach, loads of planning upfront). We would spend a WEEK planning and then code for like a month and release basically near perfect code to production. It did feel a bit boring in a way because there was very little wiggle room - everyone just followed the plan.
I did my first scrum training with Ken Schwaber. Ten years later I did it again with a "Scrum Consultant". Same "processes", but utterly different reasons, utterly different outcomes.
And there's no hope for it. Managers can't be convinced by me that Ken Schwaber didn't mean whatever bullshit their high-priced consultant is saying. Even without the consultant, there are far too many ambiguous things, that Ken gets into specifically, that don't come across when discussing Scrum. Scrum will result in the manager doing none of their responsibilities (e.g. proper planning), while micromanaging the engineers.
If I ever start another company, we will do Scrum. But otherwise, I won't go near it.
On standups: first, I rarely speak in standup; if some other manager uses it to micromanage, well, that's on them, not on the general concept of daily checkins. Second, it's very difficult to "signal progress vs. actually making it" with your teammates. That's part of the point: intra-team accountability. If you're making no progress, you might fool me with generic excuses and you can certainly fool a business analyst or a project manager, but you can't fool another programmer who works on the same code and sits next to you.
On agile having a lot of bureaucracy layers: compared to what? The agile "bureaucracy" my teams endure is: standup, refinement, and retro. That's less than two hours per week. What methodology involves less bureaucracy than that, other than anarchy?
On points: OK I will kind of give you this one, but only because they don't bring value to you. Story points aren't for you, the dev, they're for PM and execs. What do execs want, in terms of estimates? They want to know exactly when a feature is going to ship, to the day, even if it's years away. What do devs want, in terms of estimates? To not give one, ever, for anything. Story points are the compromise. And pointing a story takes maybe 30 seconds, so it's hard to understand how anyone can see it as onerous.
So in summary, I think agile is very good when done right, and in places where it seems bad it is usually because one of the basic ingredients (a team empowered to change their own process) is missing. That, to me, is the core of agile: a team that iterates on their own process. If your team is not willing to or allowed to do that, IMHO they're not actually agile. And if they are, well, take your objections, bring them up in retro, and propose something better.
Kanban makes so much more sense when that kind of garbage is in your work environment.
If you consider things in the Agile Manifesto and the spirit of being agile, the pros are things like you don't waste time building stuff nobody uses. Why gather requirements, design, develop, test, deploy of features that have minimal or no usage. I've seen many cases that by the time a feature gets out there, its not needed/wanted any more. There are charts and stuff on this regarding Lean Software Development. Another pro is barriers are identified quickly and can be problem-solved quickly. Figure out your unknowns really early and you can adjust what you're building.
Over the last year with everything going on there were days where at standup people said "got distracted" and that is perfectly fine. I took that to mean they didn't get anything done during the last day. There were some major life distractions this past year. Those meetings aren't for management to keep tallies on people for some fictitious scoreboard, they are there for the team to identify barriers, ask questions, etc. so the work can get done. Agile comes from lean principles from manufacturing, its about eliminating wasteful steps in a process.
Some cons would be with the wrong culture you get micro-managers, people measuring stuff that doesn't matter (ticket size, velocity, whatever) and possibly people gaming whatever nonsense you are measuring. If there is bad culture the project management process being used doesn't matter really, its not going to be pleasant working in that.
If there is high risk in what you are delivering, like if you're building software for controlling a nuclear power plant, ICU medical devices, etc. you may need a lot tighter controls around the project process because software bugs can result in really bad things. Maybe a waterfall process works better in those situations, otherwise use agile that fits the people and organization.
There are a few points that are important to it working well though:
* Team size should be small, but not pathologically so. 3-8 is about the range it is ideal.
* Strong ownership and trust between engineer and product owners, both way.
* Engineers should have broad, or at least T-shaped competencies, not narrow, exclusive focuses
* Meetings should feel useful to all participants, at all times. Specifically, standups should be useful to the POs because they get a rough idea of how things are going across the team, but it is also useful to the engineers to ensure that engineers are actually working together, not simply siloing themselves.
* Engineers should be competent, in general. They don't need to all be 10x engineers, but a team comprised mostly of leaderless junior engineers will fail, even more so with Scrum/Agile
Trust has to be the most important ingredient for a successful project regardless of the project management process, if you have trust any process can work well.
Agree about Team Size, less people less communication is needed which results in less misunderstandings == more productivity.
It's a good way to set expectations for what will be/is to be delivered in a Sprint, and limits going off-piste in too many directions while not delivering functionality (which is a problem for creative/broad-skillset developers at times).
It also limits the impact/waste in case the requirements change - you only worked two weeks in the wrong direction. (and they say changing requirements is the biggest problem in software projects since ever)
However, I find that it often reduces developers to mindless drones, just trying to satisfy acceptance criteria without thinking about the big picture. (You know you're there when Refinement meetings are very quiet and the Architect does most of the talking).
As for estimation/scoring - I find that estimating "complexity" is nonsense. Treating points as "days" is more realistic and leads to better time management from everyone.
We keep it small, team level (6 people), and they last 15 minutes.
No pressure to describe anything - you can say "I'm still working on that thing" and that's that..
Honestly it's more of a social thing, especially while remoting, and a chance to share thoughts and offer assistane.
In my mind, the benefit of agile is that it encourages a movement towards the double-loop learning model (pg 19), which is a struggle for many people and most organizations, from a single-loop learning model (pg 16) (assuming there is even a learning loop present at all).
The single-loop learning model:
Note that the loop only goes back to the decisions, not the mental models and strategies.
Mental Models of Real World | v Strategy, Structure, Decisions Rules | v Decisions <------------+ | | v | Real World | | | v | Information Feedback --+
The double-loop learning model (another ASCII art attempt) closes the loop and brings the feedback back to the mental models (using abbreviations to shrink it a bit):
Agile promotes exactly this sort of thing, which many process-centric organizations do not. Waterfall doesn't promote learning. Most processes, as written or as implemented, fail to promote this learning and updating effort. For people willing to step back and read the Agile Manifesto, to read some of the texts on Lean (manufacturing or software), to read about the origin of the idea of DevOps (rather than assuming it's a job title), to read about the Theory of Constraints, you'll see this continuous learning and improving element is common to all of them and to many of the case studies. It's not about standups, it's not about time boxing, it's not about cross-functional teams. It's the ability to introspect, learn, and adapt.
MM ------> SSDR ^| | |v v IF------->Decisions ^ | | | +--- RW <---+
I actually just bought this book - is it any good? :)
Seems like your company is doing it wrong;) Agile is supposed to 1. remove bureaucracy, not add some; 2. adapt to the situation. Before Agile, you would read specs and implement them, and those specs had been carefully written by a team of analysts (8 people for a year). Any change to specs had to circle around the analysts and customers. Agile should first be an improvement on top of that.
But if Agile is still getting in your way, seek to remove that too, and your managers will be happy. Agile should be about adapting. Anything that does not bring features is unnecessary.
Last note for humor: “The wrong way to do Agile” depicts how things actually happened in Waterfall: https://youtu.be/l1yWusiaLCM
1. Better visibility of progress and blocking issues - this is a big plus to senior mgmt and if you're technical it will help you alot that they understand you're making progress rather than being a blackbox that they hope delivers something in 6 months time
2. More adaptable to change - every project changes, the lnger it runs the less suitable it is at the end. Agile/Scrum theoretically allows you to change course better (not that you couldn't do it under waterfall..)
You do make a good point that it can be a dream for micro managers if you're unlucky enough to work for one, there are many potential faults but it depends on who's in the team frankly. The standups can become mundane and useless if people can't be honest about blockers or where they need help as well.
SAFe for larger orgs or Kanban for smaller teams are excellent approaches to agile.
The book 2nd Generation Lean Product Development really gets into the weeds on what works and why.
The game industry is a famous example where scrum just does not work. There are to many pipelines and to many disciplines, and everything depends on shipping.
So in the game / VFX industry there is most of the time a strict waterfall structure that does not help you to do scrum. If the hours a team is spening on a sprint is not the same every time then you are just using postid notes to track the progress. (crunch hours are unfortunately very common in the game industry)
So in general I would say, Scrum/Agile is definitely beneficial if you are shipping multiple versions of a product. But if its all about shipping 1 final product or if the time team members are going to work on it is not specified then you are just using it to track you progress and it is therefor not any better then good communication.
from Pragmatic Dave Thomas: Agile is Dead https://www.youtube.com/watch?v=a-BOSpxYJ9M
Cons: everything else :-)
I enjoy the non-scrum world, but every time I try it, I realize how bad it actually is for everyone involved, especially if there are timelines. But also I think unless you're sufficiently experienced, Scrum is micromanagement hell indeed.
You can't streamline software development. I don't know why people keep trying.
Also our agile approaches mostly work out well, but our whole organization is structured in a way that facilitates this.
We have only 2 levels of hierarchy and crossfunctional groups for arbitrary topics like "wage transparency", "consulting" or "technology". Anyone interested can take part in those and they get some budget too.
Every few weeks there are townhalls where economic development is reported by the executives to the rest of the company and anyone can ask questions. Since covid we do this via google meet with great success.
All in all agile approaches only truly work if acceptance from the higher ups is high. If agile is just used to get tighter deadlines out of devs it is actively harmful.
Daily meetings are not to micromanage and show off that you've done so much work yesterday, but to identify issues that need to be resolved and a good place to ask the team for help if you're stuck.
Unfortunately, agile nowadays is mostly scrum, following some non sensical plan taught by some agile coach and too much management, whereas agile was invented solely by and for developers (not managers).
`Dr. Andrew's has certainly given his opinion about what we should do next with the patient, but what does Fred think? Fred says masks are pointless. Dr. Andrew, we're all equals here, you shouldn't let your emotions take over. We'd like you to perform this surgery without a mask...`
Luckily, it's just a software management technique, and generally speaking there are enough adults in the room that it moves forward regardless...
If by "micromanagers" you mean, "just managers who like to understand how time is being spent", then yes that is what Scrum/KANBAN are for, among other things.
I remember working at a startup in the UK around 2013/2014. We had guy working for us who did the UI for the portal our customers used to interact with our service. We had another developer doing the back end in Ruby on Rails.
At this point in time we didn't do Scrum so as a result we didn't do daily stand ups. We also didn't do any form of TDD, BDD or any testing at the code/module/lib level at all.
Fast forward a few months and another programmer joined the team. Really great programmer and big on testing and Scrum. He convinced the CTO to try Scrum and go with daily stand-ups, planning meetings and retrospectives. That was all he was asking. The CTO agreed.
The UI was fired a week later. Turns out he had spent two weeks allowing the side menu slide in and out from the left of the web page. He did this from scratch.
The new guy then convinced the CTO that TDD was important for at least the critical paths through our application. He wasn't asking for 100% code coverage, nor would he (because he's smarter than that.) The CTO agreed.
The back end guy upped and left two months later. Turns out he didn't like doing testing of any kind, so instead of writing useful, meaningful tests, he wrote tests that simply returned "true".
The lesson from this is: Scrum can, like systems, highlight problems inside of an organisation. By implementing Scrum were got a daily snapshot of what everyone was doing, keeping people accountable for their actions, and knocking down blockers sooner rather than later. There is no "micromanagement" here.
These simple systems, like TDD, Scrum, OKRs, and so on, are excellent when used correctly.
* Frequent feedback from stakeholders and customers
These can be annoying but they help make sure that the right thing is developed.
Things I don't like:
* Things get rushed to get them done before the sprint ends (even if there is no deadline pressure)
* On the other hand, everything takes at least two weeks to get done
I feel that this turns the output of a very high-performing developer into that of a mediocre developer. I'm not a 10x developer, so I can cope. ;)
Things I don't like but don't blame on Scrum:
* Estimating: All estimates beyond the current sprint are completely unreliable. Still, people use storypoints to derive release dates and worse, measure the productivity of employees using them.
FWIW, until I learn of better processes, I prefer Scrum without "buts" and with continuous deployment.
Communication is important (vitally so), just the format is entirely wrong imho.
However scrum can really suck if executed poorly, especially the daily syncs. One of the keys I think is taking things offline and not ratholing, enforcing the time limit (15min), and if there's any manager or PM present not doing engineering work they cannot speak unless spoken to, or perhaps once at the end with any short updates/concerns w.r.t. backlog.
In the end it depends on the people, and the biggest thing that can make or break this is the product owner. We had someone as a product owner who had absolutely no political play in the game, he was a designer that stepped in and understood the product. All he did was explain some quirks and come in to help if there are questions or things that are not clear. On the other hand, when the product owner tires to be a manager of the team and the processes, it all goes extremely wrong.
In most circumstances, one or two updates a week would be fine, preferably followed by the rest of update meetings so more contiguous hours of problem solving can happen.
The idea that we could have a call at a fixed time each day to figure out and reorient active development priorities is a manager's fantasy.
Some developers need a whole week to get momentum on very difficult tasks. Breaking their time up into discrete 24 hour chunks where they have to constantly report ambiguous progress can create incredible amounts of unnecessary stress over time.
We are now operating 100% async. I worked with our implementation group to ensure we have a buffer of priority issues so that developers always have a way to grab the next task, even if it's 3am on Saturday. Some people get inspired at weird times and that's totally fine.
When I first started, we operated on textbook Waterfall standards - I'd be handed an issue from my manager, I'd spend an unspecified amount of time trying to fix it or implement it, and repeat. I had no context about what my other colleagues were doing, or about the greater scope of the project. We had several projects going on at once, which frequently missed deadlines or changed scope halfway through. I might spend a day on an issue, or two weeks - there was no assessment of how complex an issue was. Due to the age of the codebase, various parts of it had no unit tests or documentation.
Some of my other colleagues proposed using Scrum to organise a new project they were working on. Issues were organised, broken down as small as possible, and progress was delivered in Sprints. They estimated their issues, estimated a delivery date for each phase, and met it. They also implemented unit tests and completed documentation for the code.
Over time this method was expanded out to all new projects, with my colleagues organised into teams who focused on one project at a time (while handling maintenance of the older system).
I've found that pairing Scrum with other modern development techniques like unit testing and MVC architecture has made the projects much more maintainable and has given the teams more investment in driving the projects.
We use three parts of Scrum - standups, weekly sizings, reviews. While retrospectives were important early on, mostly everyone is happy with the level of Scrum we practice. A key thing is to not let these meetings overrun - that seems to be everyone's main complaint about Scrum is not letting it distract from actual work, but using the time to better plan it out. My managers can see the progress of a project in rea-time as well, between reviews and looking at the team burn-down mid-Sprint. We can better track issues that people are struggling with on a day-to-day basis.
I've now found it a lot easier to deliver projects on time, and to better justify why delays occur because of the increased amount of planning. My team members are now better invested in the project and morale is much higher. I see Scrum as enabling picking up other good practices as well, but it's not worth doing if you're not also pairing it with these other techniques, or it's just a way for management to hold lots of meetings. It really requires a team-based focus, which is why I think a lot of lone wolf programmers bounce off it.
Beyond that, it's just a way of doing things, much like an OS. It doesn't matter if you're running W10, MacOS, or some flavor of Linux. If it's the right tool for the job, then it's the right tool for the job. But if it's not, then why is it in use?
Agile/xp started at Chrysler as a way to push back on management on give engineers a chance to pace/structure/set expectations for their work
Modern agile is just a management framework used as an excuse to micro manage the shit out of your work force.
You need to take in consideration what scrum makes you do (stand up meeting,...) but also what it is meant to prevent and you shouldn't usually do (interruptions and working on requirements that change daily)
It's hard but when done properly it's great
The problem is that research into software engineering sucks. The silver lining is that some people have done small scale studies on this subject.
The studies I've read range from no impact to a significant improvement of using Agile methodologies over, say, waterfall processes. This large variability is a hint of how inconsistent these studies are, but I've seen more evidence piling up in the "good" side of the scale.
However, from your loaded comment seems clear you aren't really interested in data anyway.
The parts I didn't think worked:
* Retrospectives which had no actions as an outcome
* Daily stand ups that were led by a project manager who discussed each persons work 1 to 1 within the group
* Bugs not really fitting into the flow of work
* A poor planning session can set up a bad sprint
* Sprints often ending without any working software
* Team members working in silos
* Outside dependencies blocking work
* Estimating turning into 'how many hours will this take?'
* People reporting working on two or three things every standup
* and the worst imo, work not on the sprint board that must be done
The cons are it's a huge waste of my time.
I much prefer a system where someone just tells me what they want/expect, and leaves me alone while I do it.
I have no idea how tracking should be done.
What I’ve seen work best is just a quick “hey this is what I’m doing today/this week, will depend on yyy” so that anyone who depends on what you’re doing (or not doing) knows; alternatively, “wait, you’re depending on my project yyy?”, no discussion except, “hey, let’s talk directly after this”.
Not for any manager’s benefit, just for each others’. Like a code review there should be no judgement. If anybody wants discussion do it elsewhere so everybody else can get on with things.
SCRUM/AGILE/whatever for development and product teams is a red flag for me. I find that bi-weekly demo days seem to set a better culture and pace for things without the constant oversight.
Sprinkle in some weekly "forums" across teams to chat, BS, and discuss issues. Invite people to bring their agenda questions, concerns, etc.
The biggest thing (especially in remote) is that all your humans have visibility to the other humans in a semi-consistent basis. The org-chart matters.
Also, the bean counters have won. In most enterprise companies "Agile" is nothing more than top down micromanagement.
However, it is essential to keep in mind why these things are done and not just cargo cult them.
I have felt Scrum is cargo cult agile which helps non technical managers retain power post "agile transformation" in the form of "scrum master". Just that title changes the power balance in meetings and kills the spirit of what they are meant for.
but we dropped that bullshit like "story points" - you know, abstraction over abstraction of time/effort whatever it is.
we estimate stuff in man hours.
The ideas behind agility in software development were all about reducing bureaucracy, focusing on small slices straight to the customer, strong focus on quality and testing practices and continually readjusting and improving. None of it was ever about stand ups, estimation, using Jira etc.
To make a meeting matter, make a decision. You can make the daily stand up ritual into something meaningful to the participants, if you recast it as “let’s decide what we’re gonna do today.” If it is just a progress update, then it can be done better asynchronously.
But, the daily stand up actually does increase productivity as a status update, if the work is not planned out properly. So let me get into what that means: in theory, on any software project, there is a dependency graph of steps which have to be done in order to achieve the next release. This graph also has implicit dependencies just because we have finite resources and one person can't do everything at once. The steps also come with some time estimate, and then we know that there is uncertainty in that estimate so we add safety buffer. Whether the work is planned out properly comes down to whether this safety buffer is spent, or squandered. If the most important thing is not being worked on, if it is sitting waiting for review say, or if it is just an ugly messy task that nobody wants to pick up: then your safety buffer is getting spent but you're not getting much for it. And the easiest place that this happens is at the start of a new release when there seems to be so much abundant safety buffer that it is now time to play and relax and experiment with random ideas. In fact, give arbitrary amounts of safety buffer to a poorly planned software project, and it will overrun whatever buffer you give it, simply because of this lack of urgency at the start, it becomes even less urgent if it's not due in one quarter but is instead due in three quarters.
So that is where standup comes in and imposes an artificial urgency. And somebody randomly happens to work on the critical path and it starts moving forward. Until you run into a big ugly problem that nobody wants to solve on the critical path, then the project gets delayed until there are no other things to work on, someone has to slog through the pain. you still miss the deadline but not by nearly as much as you were. Lights a candle under everyone's ass. It's not the right approach, the right approach would light a bonfire under one person's ass, the exact right person's ass, until they passed the baton to the next person.
I've subsequently seen agile/scrum very poorly several times within both large and small companies.
I like working within Agile/Scrum - when it's implemented well. But that's rare.
No methodology works right out of the box and it’s insane to think that any could. You have to look at your specific requirements and mold Agile around your team. Agile literally says to do this but most just ignore it.
The more thought you put into your methodology, the better it will work. I know most want Agile to replace critical thought because they don’t want to have a target on their back if things go wrong but there is no substitute.
Scrum is a gimmick invented to sell scrum courses. It's an easy-to-understand framework for convincing managers that their teams are agile, but I've never seen it work in practice.
Some of the scrum practices - such as daily strandups - can be extremely valuable for software teams. Standups, for example, are an opportunity for alignment, or more accurately, for correcting misalignment. And like all practices, they can be practiced badly.
- healthchecks (from Spotify squads)
- story points, and kinda compute our velocity. Well, we approximately know how many points we can do in a sprint
- say no. We routinely refuse to do stuff coming from the top of it doesn't align with our vision as engineers
- daily stand-ups. They're completely useless
- poker planning. We still evaluate tasks together but without the useless ceremonial, and autonomously reevaluate during the sprint if necessary. It's considered bad, we don't care, it works.
So by having each Sprint accounted for and signed off, whenever he barged in and demanded something new, the first question was asked - what would he like removed from the current Sprint. By him signing off that things were removed, he could no longer ask why it wasn’t completed as originally agreed to
Sounds you would like proof that scrum does not work. Instead, how about looking at the parts that could work for your team, and discuss if you should adopt?
When we need a bit more torque, we tend to adapt more process and when we have plenty of time to waste we abandon process and take it easy.
If you are lazy and dont want to work, you probably dont want processes that expose your slack.
And it also depends on how you implement it - doing it well relies on buy-in from anyone touching the dev team in any way.
So, yes it can offer benefits, for some companies, if done well.
Just renaming managers into product owners and renaming hour long meetings where you explain yourself to the manager "stand-up" is not going to get you anywhere. Doing it right involves significant change to process with no-one trying to circumvent it.
Standups aren't supposed to be about managing, there is no manager present. Ours takes 5 to 10 minutes before lunch.
However Scrum has become so formalised, so focused on certifications and titles and the exact way to do it, that it's become the opposite of what Agile was trying to achieve.
The practice varies, if done correctly it's beneficial, if done poorly it's a nightmare like any poor software engineering practice. Can't tell you definitively about how beneficial it is to the software industry, but I believe it's a net positive since it has encouraged faster shipment over big bang releases.
Most people aren’t doing agile, they’re doing a custom, lightweight version of it. This is a good practice though I still think it hurts projects; but not as much as quote unquote real agile.”
Can you make it a poll? That would be really interesting
Oh, a few months passed?
Define Agile/Scrum again, because one of the key decision makers has moved to a different role, so we’re changing things. So what’s the new definition?
Oh, some more time passed?
More org changes! Time to change the definition of Agile/Scrum again.
Now, what was the question?
“Well if you’re doing it right, it should survive though changes of management.”
Oh ok, but tell me... when did that assumption ever hold?
Sprints: What are the pros and cons of delivering working software incrementally at regular intervals?
Standups: What are the pros and cons of teams members spending 15 minutes together every day talking about their work and how they might help each other?
Cons of any product development process is not taking into account human interaction and assuming a perfect team.
Build a team first, choose process to get the best out of this team be it Agile/whatever.
That's what I want to believe anyways.
It would be interesting to see an actual study, though.
Team A does project 1 with Scrum.
Team B does project 1 without Scrum.
Let's say over 3 months.
We could look at time to finish, bugs, code quality/resilience, etc.
I know there is a 'study' out every other day from some Project Mgmt org saying, "500% of IT Projects are fail!", but obviously we need real studies.
But a good agile team will be more responsive to changing customer needs.
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan" -- Agile Manifesto
Whatever we do in agile/scrum of Today is anything but that.
I am curious to know if Teslas/SpaceXes/Googles/Stripes of the world practice Agile/Scrum?
Like with any great idea there was someone who decided to monetize it. Thats how scrum was born.
I see that with every pragmatic solution good devs try to share:
Sooner or later some “hot-shot” shows up and decides to “teach” ppl for money “how to do things correct way”.
After that great ideas turn into crap, because too many people want profit from it instead of learning from it.
Many places also do agile badly. The ones that have stand ups without a (certified) scrum master are likely doing it wrong and can often be anti-productive.
Kanban is fine though, and a good low overhead technique for multiple people in a team.
Pros: helps team uncover and jump over costly roadblocks Cons: overhead
There’s probably a better system out there. Till someone invents it, Scrum works fine for my teams
I’ve often seen coders staring at the void during so-called standups, and very weak devs closing tickets while doing almost nothing useful for the project, because their managers cared only for this metric...
Scrum, management, meetings distract at best, crush at worst, this critical creative process.
If done properly (very rarely done properly) it works as described on the box.
Most people simple use Agile as a way to generate interactive Gantt Charts that management can change willy-nilly. It's very rarely done to empower teams or improve effectiveness.
We are trying to build a new way of building value - this time using code as technology. My usual comparator is this is software literacy - and we need to look at the effects of the European literacy explosion of 1450's as a guide (renaissance Italy still kept glassblowers as virtual prisoners)
The things that are broken and I think in need of change
* Capital vs Management. Executives often capture too much value, and control too many of the allocation decisions. Huge corporations are inefficient - in a similar scale to centrally planned economies. (For example, I cannot imagine that Jeff Bezos spending billions on rockets is the most efficient means to produce value from those billions)
* command and control vs democracy. Again with the decisions best taken at small scale. How would your (big) company behave if instead of executives deciding which projects got what funding, it was voted upon by employees? It would be radically different. Would it be better? I imagine the discussion forums would look a lot like Linus' rants. How would we moderate that? Would hiring people be different? Would you hire someone politically different to you if they might vote against you? Would you even get a hiring decision?
* Project Management stops being about dates. This bugs me a lot - at some point all the nice agile - we need certain level of quality, story points are a measure of complexity not time, we discover as we go, all that falls apart and becomes a date in a plan at the board level. Mostly because the tools used at board level (and the mental models) cannot cope with ideas of alpha, beta, prod quality, or if this date slips all other dates slip too - cones of uncertainty are a good approach to this, as are other mapping functions about the relationships between features and capabiites. I dont have a good answer here either.
But there is a lot going on - its not a fad (ok Scrum might be, but this is not about scrum - or agile - its about how do we humans produce this new code thing at scale and change our society around it as we did in 1450 with words, or 1890 with cars.
If you have the skill to write code, then dismissing this as "management crap" means giving up an informed voice on one of humanities most important inflexion points since ... the last one.
Whatever you do, make sure you review all procedures to decide if they make sense for your team. Don’t follow them blindly.
Kanban is an approach with less ceremony.
I wasn't the only person that left.
Tickets come flying in, blockers get turned into a mountain from a mole hill, planning meetings are multi-hour time wasters, retrospectives cover the same things, and everybody is just nice to each other rather than raising their concerns. Deadlines are a fallacy, other than giving substance to these ritual meetings.
Kanban makes so much more sense. Allows estimation via cycle time
The Agile manifesto doesn't talk about roles or how the process should be, but Scrum does it.
Agile itself was introduced by bunch of software engineers came up with the Agile manifesto. It's simple, abstract, and effective. There are many successful tech companies that already have something more extensive than Agile. Agile manifesto is just a good starting point if you don't have anything in place.
But somehow Scrum became the recipe to implement Agile and we ended up with a job title called Scrum Master which has been increasingly taken by non technical people inside traditional organizations.
I've seen teams that implement Scrum by the book. They have a person called Scrum Master that facilitates all team meetings. It basically turns other team members into reactive players instead of proactive. But, do we really need a person to facilitate team meetings and ceremonies?
I talked with a few Scrum Masters, their job satisfaction is actually very low and even though they don't admit it to their own team, they don't believe they are adding real value. What they all have in common is that they all want to switch to a different role and they are looking for an opportunity.
I couldn’t find anything similar in other industries, and it's hard to find a successful development team that implements Scrum by the book. What you find most of the time is what is called "other Scrum flavors" and I think that's a problem in our industry. What many teams are doing isn't Scrum, but anything that has a short release cycle, a daily update in any form, and a retrospective is called Scrum.
The irony is that most of the Silicon Valley and successful tech companies don't use Scrum at all. In fact many of them don't even label what they have as Agile.
What is happening right now is many companies wasting lots of time trying to implement Scrum by the book until they fail and move on to something that they call a Scrum flavor. I think we should stop calling it Scrum so others don't have to repeat the same mistake again and again.
If a team fails, Scrum compares it to its book and says the team failed because they didn't implement Scrum properly. And when a team with one of those so-called "Scrum flavors" is successful, Scrum takes all the credit.
I personally think we should kill Scrum. We shouldn't advocate it and we shouldn't call any team with a daily update a Scrum team. Many successful tech companies don't use Scrum, but they aren't vocal about it.
A good agile process, make development work less stress.
Standup is a status meeting? Who told you that? It's a planning meeting. You plan the day with your peers. If you do it right you don't have to talk to anyone the rest of the day and just flow.
Don't listen to the consultants. Learn about real scrum from here. https://sites.google.com/a/scrumplop.org/published-patterns/...
For experimental stuff, agile could be good.
For product stuff, Scrum could be good.
For commodity stuff, six sigma could be good.
Using one of these for something it isn't meant to do will lead to failure.
What bothers me is that scrum masters are being groomed as the next-gen MBA.
too much chin wagging, not enough building too much synchronous communication
for being called agile you don't build software very quickly with it
As you note, disadvantages include micromanagement and perverse incentives.
That is to say, in a lot of ways a small clever theologically-aligned team is going to be better. But if there’s a good reason you can’t have that, scrum can help you make the most of it.
Each new book tells a different thing.
Unfortunately I've been working in backend data movement since college where the final product is very well defined in the old waterfall model. Our intermediate tables aren't any use to the internal customers and there's not really much iteration needed, they come to us with data that's somewhere other than where they need it and we bring it to where they do. Recently though our org has taken to Agile/Scrum and the results are a little painful especially with our projects that require significant infrastructure setup, all of which is owned by external teams often understaffed so their backlogs are weeks to months long and while we're waiting on provisioning or approval from governance we're stuck looking for stuff to do that will meaningfully move things forward.
For engineering and software quality? Absolutely not.
The rest is just a religion.
I had mixed experiences with it but absorbed a lot of good lessons. While I can't speak to "scrum" that much (I've seen degraded forms of it a few times but not the actual "real" thing) I think many of those fundamentals have been lost in the intervening years... err.. decades (cry).
Two things key for me, that it seems that people don't care about anymore:
i. Developers doing their own estimates. Absolutely essential to managing scope. This one always goes out the window or gets ignored first. I have worked in so many "agile" teams that would choke on their own vomit before taking the power away from managers or "experts" on the team to decide how long something will take. If this is the case, there is no point in scoping in an "agile" process anymore. You'll just have to crunch to meet their deadline, and that's that. That's not "agile" that's "sweatshop." (Or, if you routinely blow out / pad the estimates too large to compensate... inefficient)
ii. Ship the minimal viable product, and then iterate on it. You ain't gonna need it, etc. Release frequently and often and in small chunks. Absolutely foreign concept to most of the recent UX and PMs I've worked with, especially at BigCo, who treat the design doc / mock / spec as the finished product, with the actual development just being a kind of "last mile." Want to know what changed between their last giant spec document and now? Read the whole 50 pager again. My wife was taking UX design courses and even there, while paying lip service to agile there was all this type of "produce a planning document" with big upfront information hierarchies and total project design. And yes, even working in embedded and other things not front facing, I found this to some degree. A fear of iteration, still. The act of forcing the customer or PM or whatever into a discipline of an incremental thought process honestly helps with frequent delivery, and keeps the process responsible to the user, the real final customer.
What is so often missed is that agile in the classic XP sense was an exchange, some compromises: I (the engineer) agree to work rapidly and ship frequently and to give you great visibility, but you (the customer) agree to be provide me with constant feedback and prioritization, to accept my estimates/scoping, and to think incrementally and practically about what you want now rather than what you think you might need 6 months from now.
Daily standups and iteration meetings and story cards? Handy. But these are just part of the mechanics and can easily devolve into theatre or pantomime of "agile" if the other pieces aren't there.
I've worked on scrum and other types of agile project management over the last ten years. In that time, I've seen many bad implementations and only one good one. At Redbox, they had it down to a science and it worked perfectly. They had meetings for developing stories run by business analysts. They had sprint planning meetings run by scrum masters that only involved fully vetted and story-pointed stories. They used Fibonacci numbers for voting and everyone had a vote, including the QA people. They had QA people! We only started a sprint if everyone agreed on the stories. We (the developers) selected stories. We were never assigned anything. Stand ups were very quick. What are you working on, what did you complete, do you have any blockers.
The entire point of agile/scrum is transparency and to focus on delivering incremental value. Over time, that value can be packaged and reported upward to show management what features are being added or improved. No one can hide. If you're not pulling your weight or invested in your work, everyone will know within a day or two. If you legitimately have issues with your assignment, you need to communicate that and the team will help you.
The issue that comes up over and over with agile/scrum is how management and budgeting interact with the backlog and prioritization. There is often zero trust from the people writing the checks on "incremental continuous delivery". They want feature X boxed and completed by an arbitrary date. In my experience this _always_ fails. What you end up seeing is "something" being delivered by that date, but with an "acceptable" number of "defects". Which is to say the entire feature isn't really complete and everyone has agreed to lie about that fact.
So continuous delivery via an agile process is the only way to do the work and make sure things stay on the rails. The harder problem is getting people in management circles to understand this process and embrace it and set aside their old school project success reporting techniques.
Like I said. In ten years I've only seen this done well once. And then a few places did it "okay". Most places do what everyone laughingly calls "fake agile", which is a mix of waterfall and agile.
Don't get me started on things like SAFe or Pivotal. Those are ways of putting process behind agile and that breaks one of the primary tenets of agile. People over Process. It's also clearly an attempt to monetize agile through testing and certification or by putting an app in front of it.
Tracker was made because Pivotal Labs folks needed it and it was opened up to general use because clients asked for it. The idea that the rest of Pivotal's work was a plot to flog Tracker is risible. Ain't nobody gettin' rich selling complex software for $10 a month to the pickiest possible market.
That was never the purpose. Never. I'm sorry you had a bad experience and I apologise for our role in it. But Pivotal was the real thing.
Regarding the "standups", for example, they are definitely not meant to be about "micro-managing", "signalling process" or any kind of "status report" (definitely not to a manager!). The idea behind these kind of agile methodologies is to allow teams to self-organize. The standups are meant to be a brief way for the team members to catch up with each other, and seek help if necessary. There's no need to say anything if you don't feel that you need to sync with your team members, and it's definitely a way for managers to control what you are doing. When done right, they are short, concise, helpful and positive. The same idea applies to the "retrospectives". Don't call them that if you don't want, but it helps to get together as a team and see what you want to change in the current "way of doing things" - and it's good to actually have the autonomy to change it!...
About the concept of "sprints". Dividing work in sprints is both about planning and, again, about self-organization. It's about fairness in a way: leaving developers the time to deliver something, in a way, "protected" from route changes and with a clear goal of something to deliver. But it's also about not setting up goals too far in the future. Because the goal is set up in (usually) a couple of weeks time, the results can be analyzed and the product, or whatever, developed incrementally, with management reviewing the progress bi-weekly. You wouldn't want to set a goal three months in advance and discover at the end of that period all the things that you assumed were one way that were actually not that way.
"Agile" touches several points and one of them is that during work it's important to talk face-to-face about requirements and how whatever you are building is meant to work. That is, as others have commented in this thread, that it's a good thing to have a conversation during development with whoever is the representative of the product side of things to solve doubts, instead of relying on a list of requirements.
That's, from my point of view, less bureaucratic than a formal process. The regular meetings are also meant to be lightweight and to the point. You don't have to have a highly formalized process to "point" tasks. The underlying idea is to try to allocate a reasonable amount of work to a certain period. That also does not mean that bugs or unexpected issues can't be fixed during the sprint - there are ways to make all that work.
You have to understand what all these practices are for, the ideas behind the whole thing, to do them right. And you have to work with people that behave in a certain way, that have a certain good will, that have a certain working culture, the righ experience, etc. The particular circumstances will make all the difference.
I think that seeing some of the answers in this thread it seems a little bit discouraging, but, in my humble opinion, one just have to be lucky, find the right company and the right people to work with. I hope that my personal perspective helps.
First of all, I would like to address the "haters". They rant on and on about how Scrum does not work, how its slowing them, unnecessary meetings, etc. But if you look at what they say, it's always the same. They screw up, did not used it correctly. Its like when you want to cook a dinner, and burn yourself instead. Do you blame the fire? Or your stupid ass? :D
Scrum is not a silver bullet. It is not useful everywhere. For example for very small teams, who have like one, standalone responsibility, they know it well,... having Scrum is a waste. All they need is someone who will be able to give them (feature) request and they will do the job well. They are essentially self-organized.
However, for bigger teams, more complex product, more teams involved, this does not work anymore. One guys can THINK he is the owner because he coded that particular component, but there is another owner in second team and they clash. Often times people work like crazy, but the whole product does not work. All the pieces are there, but they cannot work together, gazillion ideas how to make it work, ego-driven heated discussion how we should use this library instead of this one. How everyone else is stupid because they do not integrate with us first, etc.
Scrum it is NOT a waste of time. Any fool that say a 3-4 hours during two weeks is great waste is total junior. That amount of time will never ever mean difference between "job well done" and "oh no, we fucked up again". If you are desperately thinking that the extra hour you spend coding instead of 4 daily standups (15 minute each) will save your product, then you already are on the edge of "crunch time" and doing something incredibly wrong.
Scrum - when implemented properly - provides many benefits:
1) Little to none micromanaging: The amount of micromanaging and reporting is lower, because your progress is visible without the need to actually report to the boss.
2) More option for your own time schedule: If the team evaluates that something is "hard" and give it huge number of storypoints (if you use SP), you are expected to work on it for some time and no-one will bother you like every half a day.
3) Predictability: business oriented people can easily "calculate" the time of delivery based on your predictions/estimates. You are shielded from that bullshit AND you are earning more trust every iteration, which means you have more option to do it your way.
4) Knowledge is shared: there are no silos, everyone potentially can work on anything within the competence area of the team. If someone gets sick, work just don't stop because the "owner" of the lib is out and we know nothing about it.
5) The power to stand up to the brass.
And others, I personally value those the most. And you can achieve some of those using different frameworks, but Scrum is proven to work the best all around. Also important note is that there are some basic rules for Scrum, but most of it is just recommendations. If you follow the book to the letter and do not adjust for your team, you are screwing yourselves.
The point is, "agile" emerged from accepting that building new things primarily deals with the uncertain. You plan something, and then there are the "unknown unknowns" where things will take orders of magnitude more time than planned. Additionally, more often than not it isn't even clear how the solution actually looks like or if the stakeholders even articulated what their real problem is. So the solution: just start with something and then establish a short feedback cycle to steer the next steps in the right direction, which wasn't obvious in the previous cycle. Therefore all the ceremony, like doing daily standups to resolve problems that arrive while iterating the problem space, or retro/review where progress gets presented and the next steps are agreed upon. The heart of the principle translates to "be flexible" in the face of uncertainity. This also implies that the team is trusted to decide on the spot.
In reality, "Agile" often comes in the form of something like "Scrum", which isn't agile at all. There is ceremony and cargo-culting how one should behave without any understanding _why_ to do things. Management gets sold the idea that they get a tight grip on all decisions (Micromanagement) and can closely "watch how workers perform" with a short feedback loop. Because "we cross the bridge when we come to it", all the "engineering" parts of software development are thrown out of the window and essential things like caring about sound architectures/maintainability/... are supressed. This gets even more emphasized with the usual mindset of "Velocity", translating to managers as "build more features faster, now!". This in turn leads to some early successes but mostly turns into swamps of unmaintainable glue code and after a while the voices wanting a "rewrite" become louder... back to square one. Oh, and do not forget that "Backlogs" (especially with months/years ahead planned and communicated with stakeholders) are just chunked Waterfall processes without any flexibility, ironically killing actual flexibility. Daily standups become just virtue signalling happenings where everyone agrees that they're "on schedule" or "things will take longer".
There ARE teams that deliver high-quality solutions without getting slower over time using Scrum, but know what? These teams would achieve the same with any process, including some internal Waterfall variations. Great/experienced people deliver great results, even more so if they can act autonomously.
So instead of some magical "Agile Processes" that everyone has to follow and great results will appear (in reality: they won't), my job is to increase the chances for actual success in the real world. How? by following some LEAN values (instead of processes). But here is the next catch: there are huge misunderstandings about LEAN when it comes to software development!
Classical "LEAN Production" comes from a world where physical things are manufactured in large numbers, basically doing the same thing again and again, and tries to optimize how to do this thing better/faster/cheaper. In software development the root problem is inversed: we are never actually doing the _same thing_ more than once (except cases of reinventing the wheel). All attempts to use classical LEAN Production techniques to software projects will fail miserably (except you have awesome people to begin with, see above).
Then there are the "Lean Startup" people which start with the actual problem space and cycle in "build measure learn". Makes absolute sense if you are a startup and have to find _something_ that sticks. The problem: teams that act like this are doing the job of actual business founders and require the trust to change the business itself. This doesn't work within a traditional company when you have executive teams and a management hierarchy.
So what could be done if these things don't work? Dig deeper and formulate _values_ everyone should follow. Examples:
- "decide as late as possible" -> do not lock yourself in hard technical dependencies (this will only run with MariaDB v123 on Google Cloud with Setup ABC) early on, or else you will have a hard time being flexible (like migrating to AWS Lambda because some compelling technical/business reasons). Yes this way is not able to leverage minute features of a ultra specialized solution, but chances are high something generic will do (like: we need a sql database)
- "build quality in" -> in many cases it does _not_ take significantly longer to build something that is well-tested, decoupled and documented than to hack something together, especially when you are building it right now and have all requirements in your head currently. In fact, most code that is designed with maintainability is more on the side of an asset (you can build on it) instead of a liability (should be replaced in the future/does not get used because noone understands it or its purpose/... bitrot.). So when your building blocks are actually solid, you may even become faster, which often shows in mere _weeks_ after a project starts.
- "Eliminate Waste" -> the posterchild value of LEAN... but the quintessence. Everything that prevents the team/individual to make relevant progress right now must be stopped. Relevant progress is anything that produces value for the customer (read: _not manager_!). Waiting hours for feedback if a code snippet works? Make it fast. Sitting in pointless meetings or ceremony processes? Cancel them. Deployments/Builds need mental energy to execute? Automate it. "Feature Ideas" from managers? Let them prove that it WILL bring customer value, ideally: how much. Can't stress this enough: do not build anything that does not clearly increase customer value, no matter who demands it internally, never follow the "what if..." rabbit hole or you end in feature creep and potentially dead code areas that still cost maintenance.
... and so on. You can google more infos about "LEAN Software principles: if you want. The main takeaway: act based on clearly defined values _enables_ actual agility, acting based on arbitrary processes (like Scrumfall) _decreases_ actual aglity.
But even this (my) approach has a big downside: success is measured in ... success. Whatever the Team does, they must show that there is a measurable business impact, or share why something failed (so that bad ideas will not get tried again later... and again...). This is a stark contrast to the "virtue ethics" approach many are happy with, where "trying with best (displayable) effort" is good enough and gets rewarded. I will just look at the outcome: what did you do, was it executed as good as possible within given constraints, and which impact did it have, followed by the question: what did you learn and therefore what is the next logical step?
Many people still prefer to work without the "pressure for success" for 8 hours per workday and go home, where working is just the thing one does for earning money. No issues with that, but chances are even LEAN will not work when you only have people with this mindset. Not disciminating, just my experience.
- don’t mix up Agile with Scrum...
- see Agile as aspirational (aka read an try very hard to go back to the manifesto to clear the clutter)
- see Scrum and XP as tools
- prefer XP to Scrum : yes, it’s better to have good software in the middle of a shitty process than a good process around a shitty software. believe me, good software, even in nightmarish organization can bring joy. don’t be the opposite. :-)
- be concerned about the internal well oiling of the team first and the the product: same than with the process, a good team can course-correct a bad product decision or a user backslash (to a point), the opposite is way harder...imaging trying to keep your users telling them your product is superb, it’s just that the software works half of the time...
For the’code part’
XP if you can/know, or just start with automation (basic ci/cd or cr, tests). Then raise collaboration by making it easier to ‘code together’, agree on ‘code expectations’ and communications expectations whatever that means for your lot. THEN everybody should approach their ‘quality standard threshold’. The way is just up from there: code coverage, TDD/BDD, code review, IaC, you’re already pretty ‘software agile’ at that point, but like a circus artist, reach for always more agile
Next the ‘product part’:
That’s where most Scrum consultant will hammer you with the dailys, the demos, the ceremonies and all. Back to the manifesto. Learn what your people like, what and when it makes them productive. Make it weird, unwieldy but a perfect-fit for you all.
If a consultant looked at it, it should say ‘oh, ok, that’s a weird way to do it, but I guess it could work’.
To put my money where my mouth is, here is what we do (but it’s full of our remote, bilingual, socially multi-diverse quirks).
We start and end at a demo to our C-level and business ‘patron’.
Just after the ‘last one’, we pick what we will try to demo next time. We talk about the value of it. To whom in our demo audience/user it should evoke excitement. What would be ‘minimum’ otherwise we dont show up. What would be ‘nice’ and what would be mind-blowing. We all agree what a user should see. We settle on it for the next weeks (yes, no prefixed date). In general there’s one or two ‘big things’ that would constitute ‘the meat’, we create one/two sufficiently descriptive stories with personas that should match what we discussed for the demo and Condition of Success in JIRA and put it as In Progress. Everything else, except production issues, is considered unimportant and optional. If one of us has time during build or waiting for a review, we tackle the ‘little things’.
The PO/Business DoppleGanger goes get what we need to do all that (wireframe, design, translation, legal wording, marketing spiel,...). He/She works directly with the devs that need it. We meet every Thu and Fri for 5/10 min (usualy, max 30) entirely to make sure sub-groups or individuals are not missing on what other will be doing and profit from it. We talk about what we’re working on next not the past (the past is done, stop wasting time talking about it!!! :-)). No task, no story bs, no past ‘blocker’ discussion lingering. If people want to track their stuff in github issues or JIRA, they do it on their own. But they better make sure it’s tidy and up to date cause we do not accept messy backlogs.
In between those ‘bi-weeklies’ if someone in the team need to discuss anything or are blocked, they shout on Slack and wait. If it’s an emergency, they send a mean Giphy. If they really need someone, they DM a lead. and so on. People own what/how/when they do 200% up until we approach the end of the 2 week threshold.
Then it’s about all that we achieved. The big question is asked ‘are we ready to demo’? If a majority don’t think we have enough to show, we wait another week and ask the same question. Then week 4, same. At that point we need to have a freaking good reason not to be showing something after 4 weeks. Even if it’s minimal. Even if it’s a bunch of HTTP calls and some JSON.
And we cycle.
- 2 meeting of max 30 min (you can drop of after that)
- lots of behind the scene ‘ad-hoc’ interactions per need (that respect a ‘rule of engagement for collaboration’ the team agreed on, btw)
- 1 demo, tailor-made to the actual delivered value by the team (not the dreamt one) every 2, 3 or 4 weeks
Practice wise: IaC all the way (tks Pulumi and Google Cloud team), CI/CD (with real automated delivery not CR), code-review using PR and on-demand env, fully diamond-shaped code coverage, dependabots and automated CodeSec audits, conventional commits with semantic versioning, and we’re just starting.
-> No planning (except the 40 min discussing the next demo just after the current one).
-> No poker estimate. In fact no estimates.
-> No backlog burn downs and cycle time and resolution time...
-> No WIP (technically, yes, this is Scrumban-ish with a WIP of 2...).
We do one quarterly product vision discussion with everybody that feeds team growth and high level product roadmap (no precise estimates, in terms of Q or 2 month span).
That, I believe, can be called agile :-)
In the most common case I've seen, Scrum quickly devolves into Scrum-flavored micromanagement by some combination of actual managers, business teams and "product owners". Short sprints, daily tracked tickets, process-based decision-making... all effective at taking away autonomy from the people doing the actual work.
Even if you avoid the worst sort of micromanagement, though, Scrum still has fundamental problems. The process is primarily team-oriented, which sounds great until you realize that it's creating strong psychological incentives through peer pressure—and they're the wrong incentives. Standups, Sprint Planning, velocity... etc all push people to hyper-focus on small tickets with tight deadlines without considering the broader context.
I've seen this create massive problems on teams:
1. People feel siloed on their "assigned" tickets. Having constant public deadlines means that everyone feels pressured to make visible progress on "their" work which actively stifles ad hoc collaboration. On Scrum teams, I see people guilty for asking their teammates for help!
2. For the same reasons as 1, people feel pressure not to work on anything that isn't "their" ticket. In my experience, the best way to maintain a quality codebase is for everyone to fix small problems as soon as they see them; while this is possible with some Scrum implementations, you're fighting the current. This also robs people of any ownership over their work or their code, which is another key component to quality software development.
3. Scrum incentivizes consistency above everything else, whether impact, progress or work quality. Teams get bogged down with technical debt that accumulates gradually enough for estimates to adjust, but they continue to look productive anyway. After all, slow, incremental progress is actually more consistent than fast bursty progress!
4. The nature of the processes pushes individuals away from understanding the broader context of their work, and encourages managers/product owners/etc to communicate at the wrong level of granularity. Instead of giving programmers the context they need to make effective tactical decisions, Scrum pushes for trying to adjust work through small, artificial tickets. Too much information flows from the team and not enough to the team. I've seen managers get annoyed that their programmers don't seem to care or understand the broader context of their work—where's the passion!?—but how is anyone going to understand or value context if they don't have the space to make any real decisions with it?
5. Constant public deadlines absolutely destroy psychological safety. The teams I've worked with using Scrum are consistently under more stress than other teams. It's no surprise—needing to show up to a standup every morning to say "I'm still working on X" is pretty depressing, no matter how much impact you may have in absolute terms. The process provides plenty of ways for programmers to feel like they're falling behind or letting the team down, and provides no real upside. There's little room for real creativity or agency within a heavily process- and ticket-driven system; the best you can hope for is doing your assignments faster. How can anyone really excel in that sort of setting?
I've been working in Target's AI/data science team for almost five years now, and I've worked on and with teams that were heavily into Scrum, teams that didn't treat it too seriously and teams that operated with minimal-to-nonexistant processes. Some Scrum teams did okay and some were complete trainwrecks. Much lower-process teams weren't always great themselves—there are a lot of ways to bog down software development!—but each of the most productive and innovative teams I worked with was on the low-process part of the spectrum, and people working on those teams were noticeably happier.
At this point I've spent enough time both observing and thinking about Scrum-style processes to have some strong conclusions:
1. Process imposed from the outside is usually awful. Scrum especially so.
2. Process legitimately adopted by a team can be okay—even Scrum—but still has a real chance of backfiring. Scrum especially so.
3. You don't need process for poor management, but the two seem to go hand-in-hand.
4. The best teams have leaders—formal or not—who effectively communicate context, motivation and direction then leave room for individuals to figure out how to get there and how to communicate up about it.
Now the challenge is how to help incubate environments like this myself, and how to judge whether future teams and companies have a culture like this or not.
Agile is the recognition that that in the modern world, especially in digital products, we learn new information faster than we can act on new information, and so we benefit from structures and "processes" that allow us to discover and act on information as quickly as possible. "Processes" is in quotes there because this usually translates to a _lack_ of process. Formalized process slows things down and agile wants to act fast. Agile prefers for us to live and communicate in the moment rather than through some structured form. This is also why agile tends to be a bottom-up organizational structure, giving the most agency to the people doing the work rather than managers and middlemen.
Scrum is weird, and very, _very_ misunderstood. Scrum, at its heart, is trying compensate for one of agile's "weaknesses"--or at least, what many organizations might view as a weakness: disempowered management. Most organizations aren't willing to adopt the agile values that allow them to move fast because it means higher ups have less direct control and visibility into what's going on. Scrum tries to compensate for this by introducing an agile-flavored framework that isn't really agile, but can provide organizations that won't adopt agile values with structure that can still give them a bit of what they want (namely visibility) while providing some of agile's benefits.
Scrum's Achilles Heel, however, is a tragic one: Organizations that aren't willing to adopt agile's values aren't likely to adopt Scrum's values either. So despite all the effort and "restructuring" organizations put into place to "do Scrum", they end up with the same values and processes they were already using, but now with a Scrum-like vocabulary. This is why Scrum gets a pretty bad reputation: At its best, it's not as good as agile, and at its worst, it's twisted into a mask for the processes that were the original problem. You're usually better off either doing straight agile or not bothering with either.
As for the pros and cons of the concepts and meetings, let's clear up what each of them is about:
Standup - Often used as a daily check in. This not the intended usage and doesn't do the team much good. A well-used standup is simply an opportunity for team members to expose any blockers they're encountering so that others might jump in and help if they're so able. If the team has good communication habits already, a daily stand up won't bring them much benefit. That said, it's also serves as an opportunity for shy team members, or those who don't want to bother people, to regularly get a chance at communicating their problems, so it can be practical depending on the team's personalities.
The Sprint - Most teams think of the sprint as a unit of time around which they should plan work. This is incorrect; in fast paced environment, there's no such thing as planning work reliably enough that you can assign just enough for the sprint's duration. There are too many unknown unknowns for that to work.
A sprint is the maximum amount of time the team goes between syncs about the priorities, current problems, and what works needs to be done. Sprints aren't about planning out work and getting to it, they're about making sure the team regularly aligns itself on the important things. To accomplish this, we usually have two meetings per sprint:
Grooming - A session in which the team comes together and reviews all the upcoming work, changes, etc. The goal is for everyone on the team to be familiar with what's being worked on, how the product should behave, and that product definitions/specs are clear enough for work to begin.
Retro - A session in which the team can explore organizational or other obstacles getting in the way of productivity, and then collaborate on solutions to these problems.
Checkmarks, point systems, velocity tracking--these do not contribute to productivity and are not worth incorporating into your team. Usually, the people that benefit from these are not the people who benefit from productivity, but the people who want to have "data" they can use to prove to _their_ manager that they're doing a good job (and deserve a raise/promotion).
There's a lot of depth to agile, and done properly it can be a huge boost to fast-moving teams. But it's also very easy to get lost and go down a bad road that satisfies no one. Agile is worth pursuing, but only if you have a good guide that can keep you on the right path, and the full buy in of the organization, so they don't pull out on you halfway through.
Credentials: I'm a certified level 1 Scrum master.
You cannot fix bad management or ineffective teams by applying a methodology, and many companies have both broken management and broken teams. Sprinkling “Scrum” on top won’t fix that, and there’s a widespread failure to realise that the symptoms people see are not the result of Scrum or Agile or anything else, but would exist regardless of the development process being used.
So, for example of how I find this working well: total process overhead for my teams is about two hours a week, averaged over the two-week sprint. This incorporates all of the planning, reviews, and daily standups. Outside of rare or one-off events like project kickoffs, post-mortems, or long-term roadmap discussions there are no other process-related meetings.
Daily standups are very much a “good morning” meeting to say hello, discuss plans for the day, and make arrangements with anyone who wants to team up or get some input from others. 10 minutes maximum. Development team and product owner only.
Fortnightly review meetings are the chance for all of the teams to get together and briefly talk though what they’ve been working on, since they don’t necessarily interact with each other all the time. This is a good chance to highlight anything that might affect others or ask any questions. 30 minutes with all the teams, including business development, management etc.
The retrospective is a chance to flag up and discuss any general issues or ideas - maybe proposing spending some time on fixing a frustrating bug, calling attention to something you’ve found that works well, or proposing some process change. Also a chance to thank particular people or teams for stuff they’ve helped with. Another 30 minutes again with everyone.
And finally the planning meetings. Reviewing what was completed and not completed in the previous sprint, picking out the tickets (from the backlog of work) that we want to do for the next, and then running through them to make sure we have all the details required for each one. Maybe adding some additional tickets for anything that’s missing. Then a quick planning poker estimation of story points, agreeing on an estimate for each amongst the team, followed by comparing the total estimate with the previous sprint to see if it looks roughly in-line or we have tried to pack too much in. Usually 1 hour, developers and product team only.
The developers will also spend a bit of time over the course of a sprint documenting anything they want to do as a ticket and collecting the appropriate requirements. The product team will also file tickets for anything that has to be e.g. delivered to a customer, as well as long-term roadmap items that form the bulk of the work.
That’s basically it. There are no teams of bureaucracy, or micromanagement, or “progress signalling”, or reporting, or piles of useless meetings. Just regularly checking in with each other, and periodically reviewing and adjusting what we are doing.
The goal of any of these systems is to help produce quality work at a steady pace. Take the bits that work and drop the bits that don’t. We have small teams so I’m sure the nature of the process will change over time, but I’ve worked with far larger teams that were pretty much the same.
Honestly, at this point I find it hard to think of a method of development I would prefer.
Scrum = Communism
>Besides being a dream for micromanagers, it seems to be more about signalling progress vs. actually making progress.
It is. Management being able to change direction every 1-2 weeks is fantastic for management but can be really bad for burnout.
Every day you have to talk about what you worked on and what you planned to work on like you're toddlers who can't be trusted to do work.
Every two weeks you have agonizing meetings where you're expected to analyze the past weeks, and come up with plans to improve them as a team. This sounds good on paper but after years of it, you mostly want to shoot yourself.
And that's assuming your team doesn't agree to a 1 week sprint, where the total meeting load can be 10% of the time spent working.
And that's at companies that are pretty good at it.
So yes, it's good for software delivery. But for something called agile/scrum, it's awfully process heavy, and it sucks as an engineer.
Some parts of agile definitely are reasonable, such as quick iterations, seeking feedback early (similar to fail-fast). Continuous integration is also small step evolution process.
In general, software development is as flexible as prose (or poetry) writing, so it should be organised accordingly.
In painting and sculpture one could add a lot of small changes, but usually nothing big, because oil (or watercolor) are form layers, so layers bellow cannot be changed easily.
Software is exactly the same. It must be organised as set of lawyers with stable interference, and changing them is not easy or cheap task.
In summary, all the principles from art and engineering are applicable to software, given that the media is the most flexible, so changes are way cheaper than in any other engineering discipline. Discipline is all you need.
Not a rocket science.
That said, some of the ideas in it are good, and I think these days people try to intelligently incorporate individual elements of scrum into their own process. In the long run, the influence might be net positive, even though there's a lot of damage to make up for.