The Daily Scrum is frequently misunderstood - it's actually to replan to remaining work required to achieve the sprint goal not a status update or field report.
It might well mean that you need to bring in the Product Owner to tell them the news so that together you discuss what is delivered to meet the definition of the sprint goal can be adjusted within acceptable boundaries.
If you're wondering why you should accept this definition it's because I recently attended the Scrum Patterns course run by Jim Coplien (the guy who codified the definition of the Daily Scrum and is the co-author of "A Scrum Book" with Jeff Sutherland) and heard it directly from him.
> but I have to mention a scrum master isn’t supposed to be...
This is a major problem with Scrum. There's always someone telling you you're doing it wrong. If nobody's able to implement your big idea properly, maybe the problem is with the idea or how you're explaining it, not the people trying to do it.
There's always someone telling you you're doing it wrong.
Of course there are, and they are probably paid handsomely for their insight. How is a process that wants to implement individuals and interactions over processes and tools not a parody?
If a process is so hard to implement correctly that no one is able to do it effectively, then maybe the process should be tailored to the realities of real people.
I dunno if you've ever played team sports but roughly 50% of the coach's job is figuring out what you could be doing better, and the other 50% is telling you what to do and how to do it.
I'm no scrum fanatic, but there's real value in doing estimates at the beginning of work, then reviewing how long it took at the end of work (without revising estimates mid workstream).
The point of separating these from actual time is not to make people feel better about themselves, it's about accounting for how much unplanned work there is in your organization which is different from org to org and even project to project.
By reflecting on how many "story points" some piece of work took, then you get better at estimating how much calendar time something will actually take.
FWIW, I've never seen this work in a team setting. I use it in an individual setting where I estimate work for myself, then gauge how much I can get done in the context of a project or org.
> An API that could have been completed in 2 months will now take almost 4 months because I’ve wasted time putting in artificial stopping points along the way. My imposter syndrome starts to set in, but at least management will have pretty burndown charts.
And when he delivers the API in 2 months, it's not what the customer wants and has a bunch of problems that are difficult to fix because he delivered it all at once instead of incrementally.
If the hypothetical API is taking 2 months to implement best case scenario I assume it's doing multiple things and each of those things can be done and tested piecewise.
I really think you're missing the forest for the trees. His point was simply a big task can be broken down into smaller tasks that don't necessarily magically fit into 2 week chunks, and if you pick tasks that you know you can do within 2 weeks, often you're picking between 1-2weeks worth of work, and then the work stretches to fill the time.
It's not about how many actual endpoints there are or how you actually choose to split the tasks.
Or maybe, the model is actually just rather complex and a good API cannot be just a bunch of random methods on some losely related entities.
Or maybe the non-functional aspects of the implementation need to be carefully considered before releasing an API that makes safety, correctness, security, or performance impossible.
Or maybe the developers have an inconsistent specification and delivering piece A now makes it logically impossible to ever deliver piece B, which is arguably more important, but got lower priority because noone took the time to understand the whole thing.
Not all (or even most) software developed is developed in a vacuum for a customer who has no idea what they want. Much software is developed as part of a larger system where functionality is relatively well known in advance and where rapidly iterating on potential UIs and APIs is neither needed nor useful.
There's definitely a time and a place for Agile-derived methodologies but not every project is a nail for this particular hammer.
> Much software is developed as part of a larger system where functionality is relatively well known in advance
Also, however, most software, especially 'enterprise', doesn't actually do what it's users need, and is a nightmare for it's users. That the functionality it would deliver and how it would do so was decided by managers in advance doesn't mean it actually works for those using it.
This is true, much 'enterprise' software is awful. And the key to it is that (as you accurately say) the functionality is decided by managers, rather than being determined by business analysts and UI/UX designers based on the actual users' workflows and feedback. No software development methodology is going to fix that.
Agreed 100%. But once you have people with the responsibility and authority and skill at determining based on actual users' workflows and feedback... in my opinion and experience, iterative design works -- even "rapidly iterating" ideally -- a lot lot better than assuming "functionality is relatively well known in advance", as the GP taneq suggested. Even experts at UX need iterative feedback to get it right, in fact an expert at UX is likely to know and tell you this, that's what their expertise tells them.
(And note even OP concludes by saying he does like "agile", just not "scrum" -- so taneq in arguing for avoiding rapid iteration for "functionality relatively well known in advance" is not necessarily making the same evaluation as OP either).
Part of what always happens in these discussions is we all come from our experience. I've seen it work, in such a way that convinces me it was because of it's iterative nature that it worked. taneq above, I would guess, has not.
As a field, we still haven't done great at working out a methodology to extract/abstract from these differing experiences to general consensus principles, when it comes to "how we write software". So we're all just arguing from our experiences, and such arguments show that experiences really differ. Not sure what to do with that. The arguments just go round and round. I don't think attempts to make this "empirical" and "data-driven" have proven satisfactory, they often seem to suffer from artificiality/lack of validity to me too.
(And as far as personal experience -- I think most of us who have been around 10+ years find that our opinions about 'the right way to do it' change over time, as our experiences show us different things; but that doesn't necessarily mean those who have been around longer are more likely to be right and should be defered to; clearly that defering to experience rarely happens anyway).
This is doubly true in the world of hardware integration, where you absolutely can not "rapidly iterate" on things past a certain point. If you're placing an order for 1,000,000 devices which need to pass CE and FCC certification you'd better be damn sure the thing is going to work.
Seriously, you don't plan 14 sprints at once. You plan for one sprint, and you need to synchronize with the rest od the team. Scrum is about teamwork and product iterations, if you start from "i need API with 14 endpoints" and you will do that alone then that's not Scrum.
- How do you know you need 14 endpoints?
- What do they do?
- Do you need them all delivered in one go? Why?
- Can you make something, useful to the bulk of your users, with three or four endpoints?
- Who uses the endpoints? Can they do some of their work whilst you make your endpoints?
- What goes over these endpoints?
All these, and more, affect how you build and what you build. Scrum, and agile in general, should help you organise the work (where "work" includes planning, design, collaboration, as well as build and release), and gives you space to improve the quality of the work (when it's done well).
At my current job, scrum is just a half hour meeting every day where people discuss whatever for however long and the most important is the status update to make sure management knows that you are working. The upside is we don't do sprints, retrospectives, scrum master etc. although estimates are still required. Someone will probably claim this is not scrum, the no true Scotsman fallacy. I wouldn't mind much if it wasn't early in the morning at such a shitty time it messes up the whole day's schedule by interrupting sleep for no reason. Whatever. It's management's loss as contributing meaningfully, by speaking or listening, is simply impossible. The half hour duration is extreme. It's a great argument against such meetings, regardless of what they are called, especially morning meetings. It definitely makes the whole day and especially the morning much less productive due to draining the natural energy one has in the morning. Really, I can't think of a way it could be worse other than it being earlier and longer.
I've always been quite fiercely against Scrum as a development process, and I still am in the context of constantly evolving cloud based services, but I've recently seen it being done to great effect for mobile app development.
I think this is similar to Pete Hodgson's clarification[1] that gitflow (which he originally documented) isn't suitable in that sort of environment. If you've got a constantly deployed set of artifacts it doesn't make sense to plan in two week blocks, and then freeze a release. In the world of software which has actual discrete releases then you either have a massive gap between releases as you get everything just right, or you say "every two weeks we'll release what's ready", and for that approach Scrum works really well.
When you're working on cloud hosted services the typical approach is more of releasing things as they're ready, possibly sitting behind feature flags or partial rollouts, and for that Kanban has worked much better in my experience. It gives more flexibility around changing priorities, and space for the inevitable production incidents and technical support that can suck up a week of time out of nowhere.
I agree scrum is too heavy for a release every two weeks thing, what it's good for in my book is:
You have a very big project to make and you know exactly what it needs to contain, examples:
1. you have an application that users already use but you need to move off a platform by a particular time or you are screwed. So you know exactly what you need to replicate in the new platform (your current functionality) and you have a set deadline to do it in. For me it was the company got sold and we needed to be off of Thomson Reuters platform within a year or pay over $100,000 a month to use it.
2. You have entered into a legally binding contract and you know what the application is going to need to contain and what you can drop without getting sued or not getting paid.
If it is your own application you can always stretch timelines out a bit to get to where you need to be, or you can decide to drop features to get to where you want to be. But once there are other people in there you might not be able to stretch timelines of drop features, and then you need something that gives you a way of alerting you beforehand if you're going off the rails.
you have it in sprints because you have a deadline so you can see how well you are progressing towards your goal by seeing how many issues are fixed in their sprint, going over to next sprint etc. It's not a lot of extra work to divide it into sprints, especially as you have people whose tasks are to divide things into sprints and keep track of things.
Nothing in scrum says you release every two weeks.
Most modern scrum implementations, you release every story when you're done. The sprint is just a concept for planning what stories you're going to do in those 2 weeks, and retro.
Personally I think plans and information can change in 2 weeks, so I prefer kanban.
Every time another one of those anti-agile or anti-agile-scrum pops up it seems to just be someone having a bad experience.
The point of a methodology isn't to follow the methodology, but to use what is useful. Maybe 1 or 2 weeks per sprint isn't useful. Then maybe don't do that. Or maybe you can't estimate how much time your development might take. In that case, maybe do a little more thinking instead of presenting a black hole of time to the people that pay you. Take apart the problem until you do get a sense of how complex and/or time-consuming it might be.
Same goes for the deliverables or measurable impact; just because something has a name "an endpoint, a button, a page" doesn't mean that that defines a quantity of work or defines what you can or must deliver. Plan for what you know can be made, not for what you don't know. Having 6 months of 'planned' development seems highly unlikely to be successful, why not plan 1 month at most, and re-plan when you are near the end of the run. If people keep planning things they cannot predict it's going to keep failing.
> The point of a methodology isn't to follow the methodology,
In scrum, it is. Scrum was developed for managers to distract from the fact that they know nothing about software. So the methodology is all there is. Go ahead, ask a (non developer) scrum master about why there need to be cross functional teams, when 80% of your work never crosses the component boundary. Or go ask them who priorizes bug fixing (do this when PO, Ops, and customer care share the same room, hilarious!).
I'm not sure what managers have to do with scrum here. A manager is a person that insulates business from the execution on a non-functional level.
Perhaps this is a difference in where you work (the company, the culture, the country), but here a manager is just someone who has the job of making sure there are no obstructions and people have what they need and don't get shifted around too much.
Priorities are made based in input from owners, users and developers, and cross-functional teams are something that you do in a SIG, not in a development team.
Maybe SCRUM (R) as a commercial idea has a lot of things it wants you do to, but that's not really why you'd even consider something; you consider something because it might help you or clarify something for others, and for novices it can be great if you don't have the experience, skills, insight or level of thinking to come up with a self-improving process by yourself.
The point of a methodology isn't to follow the methodology
Then what's the point? If you cherry pick whatever you feel like, then why call it Scrum?
There are people who benefit from Scrum but they are mainly not developers.
You give a set of ideas a name so that you can refer to that set. You also don't run your processes based on some process that doesn't work, you run it on something that does work.
It doesn't matter how many fancy processes are named and marketed out there if they don't work for you.
The base concept of Scrum isn't any different from the base concepts of feedback loops and self-improvement; but if you call it feedback loops and self-improvement people don't really want it. That's where that marketing bs comes in, and the whole 'certified' nonsense.
You make your units of work as clear as possible, you make them small enough so you have an idea how things are going and you measure periodically to ensure you're not blindsided by human flaws all the time.
> Also don't assign time to points, that's completely missing the point.
Yeah, yeah. We are not true Scotsmans. In every job for last 10 years there was an implicit points -> time conversion table. And management can walk in and ask why you promise to complete a task in 1 point. It makes no sense at all.
It would be ironic to resume the article but the gist is that when rather complex reasonings get distilled into few bullet points tagged with a catchy name, then they get misused and criticised for things the original idea expressly called out.
In this case you shouldn't be promising management anything because the points only mean something in the context of a team.
If you dig deeper then scrum overall is a very complex thing trying to solve non-root problems. It is very ironic that scrum is Commoditized Excellence on its own.
Scrum in a nutshell:
1) We need to periodically check product to cut invalid activity on early stages. Let's do it in sprints with defined goals!
2) Great, now we need to complete a goal to the end of a sprint. How do we know that a team will fulfill a goal? Lets plan a sprint according to team capacity!
3) What is team capacity? It is a historic velocity metric measured in time per task in past sprints. But estimating time in time units is ... ... mambo jambo ... whatever (I did not grok what is TRUE SCRUM explanation is) ... bad, sorta. So we introduce points to estimate task size.
4) How do we estimate? Planning poker every sprint!
5) And let's add formal process to evaluate every sprint to be more serious!
It's an artificial construct to solve point 2) only. Drop a goal completion requirement and scrum will not be needed.
If you remove buzzwords though it makes more sense:
1) It is impossible to have specs for a complete project at the beginning. So let's ship piece by piece and accommodate spec changes as they are discovered.
2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future.
3) Since we can't estimate task duration precisely because nobody ever managed to do it, let's find some measure on how much work we can get done.
4) How do we estimate this: empirically by progressive approximation.
5) This is not actually necessary.
Also I think that one of the more interesting parts of the planning poker is discussing the why a task may or may not take a long time. It can give insight into system complexity to people less familiar with a specific part of the project.
I must say though that the goal completion was more of a unicorn where I worked. We always had sprints overspill to the next one but that was not necessarily an issue.
If there is one thing I dislike about the scrum it is the rigidity which is often introduced. I think a laid back approach to it makes it more useful.
> 2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future.
Backlog on every level is always non-empty. So sprint filling is not a problem. Planning step is not about visibility. You can have a near roadmap with any process.
But scrum tries to promise that we put only particular amount of tasks to be able to finish it. Sorta, in my experience there were only few finished sprint cases in different jobs with different teams, with and without scrum master. And from this moment scrum goes over the rails. Why we need this restriction at first place?
Right, the best thing about points is that they're not time.
If they're time, you get held to it. People vaguely responsible for your rumeneration might look at ponder, "Why did it take eterm 3 days to complete that 6 hour task? He must be slacking!".
Points abstracts it away, so you don't get held to account over how long work took but instead hold the estimates to account in a fair way.
I've yet to find myself in a scrum or agile situation that wasn't dysfunctional.
The most common sin is the standup, where each person talks for 5 minutes about something while everyone else tunes out. It's a complete waste of 30 minutes a day, made worse because you're tired of standing and just want to get back to doing things or meeting with people you actually need to meet with. I understand the theory behind it, but I haven't seen that actually happen in my entire 25 year career.
Next up is the sprint, which I've actually seen work somewhat in some companies. Generally, when they're doing it right, they'll have a "next up" lane for things that someone is serious about, in priority order, and actively maintained by the stakeholders (with an arbiter). And then the "backlog" is a black hole where things go to die (which isn't a bad thing). People grab from the "next up" lane the things they think they can get done in a sprint (keeping in mind the priorities), and off they go. That's the best case. More commonly, it's a morass of crap nobody cares about anymore, complete with questionable tasks, top-down requests (with no pipeline to discuss), or not broken down into manageable chunks.
Generally, when companies adopt "agile", there's a lot of paperwork, meetings and activity, but very little communication and accomplishment. The only worse thing I can think of is peer reviews.
No, you haven't. The problem is the useless interruption and waste of time that saps your flow, and the aggravation of scheduling your daily activities around it. The duration of this interruption only serves to make a bad thing even worse. Even if it were only 5 minutes, it would still be a problem because you're still stuck in a meeting that's not accomplishing anything useful.
If it’s the first thing done in the morning it doesn’t interrupt anyone, and I’ve personally gotten more than my five minutes of value out of standups.
But what is "first thing in the morning"? 8:00? 9:00? 10:00?
If different people start at different times (the norm in tech), then there's no such thing as "first thing in the morning". You must interrupt people, which means that you should make sure it's more beneficial than the cost of interrupted flow.
Because at that exact time, you must stop what you're doing and do something else, regardless of your flow state. This is why regularly scheduled meetings should meet a high bar of benefit to offset the potential interrupt cost.
As a former manager I had enormous fun tweaking and tuning the morning stand up to actually get it into a useful state. As with anything involving people there are complex dynamics, there are people who talk too much, talk too little, go off on tangents, only talk about what they want to do, don't mention blocks, insist on asking questions, Some talk too much- but only if they're the first to talk, some will always talk as much as the person before them.
It is very very difficult to get a group of engineers to have a productive stand up meeting.
"It is very very difficult to get a group of engineers to have a productive stand up meeting."
Most likely because it's such an artificial construct. There are some people who will only talk when forced to. Others just won't shut up. Others try to embellish because they may not have "enough" to report at that time and don't want to look bad.
Ultimately, my experience has been that stand-up meetings slowly devolve over time into status reports, people don't listen during meetings, and if someone needs to know something, you pull them aside later talk with them (because it's almost certainly going to take longer than your stand-up allotment).
I just can't see any actual benefit to this process that was invented out of whole cloth (not to say that trying new things is bad - even invented things; rather, they should be tested and measured). What can't be measured can't be invalidated.
It's true they're difficult to do well, but there's just as many problems with not having standups. Engineers get stuck and don't ask for help in a timely fashion, projects slowly slip and no one raises it, people start reproducing work someone else has already worked on, people find blockers but they aren't highlighted to everyone to get it fixed etc. etc. etc. And often those problems are more convenient problems to have for the engineers but impact the business badly.
The key is being intentional about your process, no matter what that process is. If you can put in place strategies to solve all the problems standups are meant to solve, that's great, but the standups weren't originally designed by middle management, they were designed by engineers for a purpose.
Did you work at many different companies, one or a few? It's interesting to me because I don't recognize this at all.
Quite the opposite. Standup take no longer than 15 minutes, we frequently address issues which otherwise would have led to lots of rework. You need some discipline to do it right however.
Lot's of engineers are afraid to ask for help, or too proud. The standup helps people get help sooner. It also often shows where two people are actually doing the same thing, take a wrong path, help prioritize etc. I can't imagine a software project without a standup anymore.
It's funny, if I would pick out the two single most valuable things out of agile I would say standup and peer review.
I've worked at many different companies. The first were all waterfall (because XP hadn't been invented yet). My next scrum team sizes were 5 (scrum), 3 (no scrum), 2 (no scrum), 15 (waterfall), 4 (scrum), 4-10 over time (scrum), 5 (scrum), 6 (scrum), 9 (scrum).
I've never seen what you describe actually happen (although I know that this is the theory behind it).
TBH I haven't really noticed much difference in the accomplishments of scrum and non-scrum teams.
Agile software development is like Communism. It always turns into a disastrous clusterfuck, and when it does, there's always some Agile expert nearby to scream, "it just failed because they weren't doing it right!"
Scrum is a way to take a below average or poor developer and turn them into an average developer.
It's also great at taking great developers and turning them into average developers.
Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum. It's just everyone trying to pick the low hanging fruit. THere's no incentive to be smart and to take time to think about solutions, if nothing is moving across what are you even doing? You're letting the team down! The velocity is falling!
I think if you have hard problems to solve you solve them by giving them to smart people then leaving them the fuck alone. You don't constantly harras them everyday demanding to know what they did yesterday and what they plan to do today. With daily updates where is the incentive for the smart people to work on the hard problems? They now have the same incentive as the junior developer, find the easiest tickets to move across the board.
Sometimes I will want to just be alone and think about a solution for a few days. If I do that though I'd have nothing to say at the scrum. So instead I'll pick the user story where the colour on a front end was the wrong shade of green or a spelling mistake! See, I knocked out 2 stories in one day, before lunch! Go me!
And it all looks like progress because stupid cards are moving across a pointless board.
Scrum exists because managers don't trust developers to get things done without constant supervision and an ever present threat of looking bad for your team.
It takes a team of potentially really smart people and turns them into a code production line. It's depressing.
I’ve had good experiences with scrum helping a team that has both experienced (10+ yrs) and junior (straight out of college) devs be productive. Letting the junior devs take the easy tickets allows the seniors to focus on the hard problems while the junior devs learn the system.
But that only works when management is willing to say “this ticket will be on the board for a while and that’s okay, we won’t harass you about it.” That is, scrum is decent for organization but bad for management.
A good tipoff is how long standup lasts. It should be no longer than 15 minutes for a team of six, and that’s stretching it. Aim for 1-2 minutes of talking. That’s more than enough to say “I worked on tickets X and Y, I’m stuck on A and making good progress on B.”
Effectively nails it. OP sounds like he has bad product owners and ticket grooming, in some ways. Management buy-in to the different "forms" a ticket can take is important to avoid Scrum Masters making velocity charts and other various job-justifying tools that they display to themselves for themselves but hold their teams accountable for.
This seems to be my (management) take on it. The agile environments I've been involved in, all I see are the 'scrum masters' flogging everyone to clear all the tickets by some arbitrary date, no matter what they are. I've had to step in and say 'I'd rather this get done right than get done on your timeline' more than once. Pretty much why I've never bought into it...
If saying "I spent all day in front of whiteboard trying to work out the best solution to this problem" isn't an acceptable thing to say in your daily standup then your project manager needs speaking to. With my team not only is that acceptable, but we include cards in the planning process for specifically that sort of thing, with a note on them saying they're going to spawn more once we have an idea of what the solution actually is.
> spawn more once we have an idea of what the solution actually is
That's really the key a lot of development orgs miss. You have to actually break down the work into smaller pieces and track progress on those pieces. "This feature will take 3 months to do. I will start now and three months later, a working feature will pop out of the black box." - will give most Project Managers a heart attack. "This feature will take 3 months to do. I'll take a few days to break it down into approximately 1-week sized milestones and throughout development we can talk about progress vs. those milestones." - ahhh, that's much better!
> Scrum is a way to take a below average or poor developer and turn them into an average developer.
It's also great at taking great developers and turning them into average developers.
Given the available pool of poor/average/great developers, this may be the correct decision.
Model: There are a1, a2, a3 developers of poor/average/quality. Poor developers cost p1, have a default productivity of q1. Average developers cost and produce p2, q2 and great developers cost, produce p3, q3. Scrum brings everyone's productivity to q2. Note that no one gets a raise or pay cut.
Without Scrum your total payoff is
a1*(q1-p1) + a2*(q2-p2) + a3*(q3-p3)
With Scrum it becomes
a1*(q2-p1) + a2*(q2-p2) + a3*(q2-p3)
So what you need from Scrum to be worthwhile is that
a1*q2 + a3*q2 > a1*q1 + a3*q3
i.e.
(a1/a3) > (q3-q2)/(q2-q1)
Now, let's say 60% of programmers are poor; a1/a3 is 1.5.
q2 - q1 > 3q3 - 3q2
So even if poor developers improve by 1/3 while great developers are downgraded by 1, we're better off.
But bad developers are cheaper and also more interchangeable.
Of course star developers hate Scrum. But star developer code is often crummy too, and technology advances so fast that I'm glad for every dollar I didn't pay for divine Win32 code.
> So even if poor developers improve by 1/3 while great developers are downgraded by 1, we're better off.
Ye... No. Note that your made-up productivity algebra model crumbles as soon as you stop seeing developers as code churning machine and instead as what they should be, problem solvers. That's because quantity is not the only metric by which you can measure problems. Complexity and ease are others. A dozen average problems do not necessarily equate a single hard one. Hard problems can prove elusive to average devs and they're usually where you see materialize the limitations of the thinking that a single great developer can simply be replaced with a dozen average ones. One such manifestation is commonly called "technical debt".
Sadly, there is one reason you might want to take a team of highly experienced developers and hamstring them with Scrum: not all highly experienced developers can or will stay focused on getting the product out the door.
I've run into situations recently where the work that nobody wants to do never gets done. Even experienced engineers fall into the trap of only wanting to work on interesting features and nobody wants to do the "needs to be done" shit work.
The deadline rapidly approaches, the senior engineers are working on whatever they want to work on and it's the dev lead who stays up late and gets done what needs to be done before the deadline. Lather, rinse and repeat for a few releases and you realize why even good managers fall to the temptation of micromanagement.
> Scrum exists because managers don't trust developers to get things done without constant supervision
it's not that they don't trust them, it's that they don't get things done without constant supervision.
> potentially really smart people
potential is not actual. in actuality, most of your coworkers are decidedly average. and the average coder, like the average driver, isn't that great.
the solution for smart people (who also produce), is to not work at these places. easy.
i say this having only worked at 2 places that do scrum. both of those places had only enough superstars to count on one hand, and the rest of the staff were dullards. yet, they got things done, thanks to the micromanagement of scrum. i didn't participate in the scrum, because f' that.
That's behavior tells me more about you than about Scrum itself.
In my team, we are just able to take the S cards, when the L cards are done. If a Junior get a L card, a senior will come and pair with him/her. Nobody tries to be clever, we all try to move forward together. As a Team.
The purpose of the Daily Scrum is not for the developers to report what they did yesterday and what they will do today. Manager, Scrum Master and Product Owner are all not participants of the Daily Scrum. Velocity is not a metric for reporting but for the team to plan their work.
I look at it this way: Agile is a bare-minimum project management methodology. That can mean different things for everyone, so look at "traditional Agile practices" as a menu rather than a recipe. If scrums don't work for your team, then either don't do them or find a way to make them more useful.
I've always felt that most companies do "scrums" wrong. It's not supposed to be an hour-long status report; it's supposed to be a 15-minute check-in to identify blockers and connect people so those issues can be addressed outside of the scrum. A good scrummaster should be able to clamp down on the "status report" aspect of it, but it's really hard to find a good scrummaster since it's largely seen/compensated as an entry-level position.
Estimate the work that comes in, commit to that work for x amount of time +/- 5-10% variance, evaluate ability to finish it all, and re-balance accordingly, all in all is a pretty effective productivity approach.
When the alternative is a near certainty miss of waterfall and tremendous, tremendous cost overages, then scrum starts to look like the less ugly dance partner.
Consistent challenges I see for anti-Scrum arguments:
1) Their POs are doing a horrible job defining what an MVP is, or the devs aren't following good MVP practices. The MVP solution as something that works outside of Scrum is well proven in numerous other contexts, regardless of what a developer designing an API may think.
2) Their Scrum Masters are allowed to turn into managers, not process governors. The silly SM metrics SMs start to make to increase their job justification suddenly govern teams and paychecks.
3) Their management doesn't understand what POs and SMs are really supposed to do.
4) Ok, present an alternative to Scrum, waterfall, in a way that works with financial reporting and accountability to the people that pay the bills and paychecks. This is the major sticking point. Criticize Scrum :thumbsup: Come up with an alternative that meshes with the reality of software the profit-seeking business :silence:.
I think the theory of scrum is great. When you think about it, Scrum does most of everything that we should be doing. Thinking about problems before tackle them. Talking everyday about the problems in case someone needs help. Course correcting when you need to.
The problem is management. Tools (burn down charts) now become executive metrics. Amount of code completed now becomes a review item for advancement. We've applied measures to things that are inappropriate for what they are used for, and because of this honest communication has been replaced with guarded statements to make sure that the team never stumbles with its work. No matter what process an organization uses in those places will fail, because management wants to hear things are running fine.
Sort of a whirlwind tour of all the misconceptions the average dev might have about agile/scrum.
Yet again, here goes.
- The problem here is dogmatism, both yours and whoever is "doing scrum" to you. There is no Scotsman! He ran away. That is, it's only if you're insisting whether you're doing it right or wrong can you start to have the conversation about what is right or wrong. Your premise is invalid.
- Confusion over terms. These things are much better represented mentally by the image of a bookstore. You arrive at a bookstore and want to read up on some stuff related to teams and planning. Cool! There's a scrum section, just next to the agile section. Guess what? The books don't all agree with one another, and that's fine. It's a marketing term, a place to go for ideas.
It gets worse after that, with dysfunctions of estimating and so forth, but you start out with your head in the wrong place, whether you love X or hate X, it's not going to end well. Do stuff you like, make stuff people want, and get stuff done. If that's not working for you, here's some titles of sections in the bookstore where you might want to read some other stuff. There are other sections. If you find some sections that have cool stuff, let me know. I might could learn some neat stuff I might use one day.
That's it. It's nothing more complicated than that. You can go to those sections and learn a whole bunch of stuff about various problems you might have. Try some if you like. Or not. What you can't do is go to that section and pull some book out as if it were a recipe and then "implement" it on a team or organization. It doesn't work like that, and it's never going to work like that, whether your view is from the top or bottom of an org. You're doing it backwards. It hurts when you do that? Ok. So stop doing it that way.
Scrum isn't for everybody. I would say it is for organisations or departments whose business is not developing products, but who develop products to service their business needs. For everyone else, there are many better options to choose from.
That said, lets clear up some misinformation:
1) Scrum is vague? It said it right there: "Scrum is a framework" - Scrum is NOT a process, technique, or definitive method.
2) On delivery windows - "I’m not against management being informed… but at what cost?". Scrum works well for businesses/departments that have a development need, not where the business IS development. It needs to fit into the business, not vice versa, and that means managing stakeholder expectations.
3) On scrum managers - "let the lead developers handle the job." Of course! Or your development team manager, depending on your org setup. The roles in scrum are ROLES - not a new org structure.
4) Estimates - sure, points are stupid. They literally make no sense. They aren't prescribed by scrum in any way, shape, or form. There is nothing wrong with using time as an estimate. Period.
I think the target audience of Scrum could be made a LOT more clear. It would save a lot of heartache and hate. I think successful marketing and certification have become the chief enemy of Scrum - orgs have tried to shoehorn it in everywhere, and thats not what it is for.
The way I get the most stuff done is meeting with the rest of my team every two weeks to:
- Look at what stuff needs to be done next, based on the stuff we want to do, stuff that other people want us to do, and stuff we don't want to do but need to do anyway
- Figure out between us how much work is involved in doing that stuff
- Review how much stuff we did in the last two weeks to see if we did what we expected to
- Use that information to agree between us how much of that stuff we think we can do in the next two weeks
- Make sure that we have all of the information and prerequisites to do that stuff
- Based on all that, to estimate how long all the stuff will take, pick which stuff that we expect to be able to reasonably do, and prioritise what's most important
Then every day, we check in for 10 minutes to see if there are any problems doing the stuff, if unexpected stuff needs to be done urgently, or if we want to show the stuff to anyone else.
Once every two weeks, we show everyone else what stuff we did and answer any questions about it; once every couple of months, we all sit down together with other people, look at our list of stuff that we want to do over the next six months, make sure we all agree on what the plans are over that timeframe, and make any adjustments we think we need to.
Someone is in charge of making sure that all those things happen, that everyone has what they need to do their stuff, and that everyone outside the team knows what stuff is being done.
This is just Scrum using words that don't piss engineers off to the same extent. Scrum is nothing particularly special or magic – it just provides a basic set of tools and terms to describe a bunch of interactions and help keep them on track, and they are for the most part pretty reasonably tools.
And here's the reason this is not a good article – it makes the same basic mistake as many others do and assumes that a development framework is somehow supposed to magically fix your broken team. A bad manager is a bad manager, regardless of whether you call them a "scrum master" or something else.
In my experience, the vast majority of developers grousing about scrum and agile are mostly mad they're being made to (a) talk to their coworkers or attend ANY meeting at all or (b) account for their work.
But hey, it's HN, so I'm sure there will be absolutely no other positive comments about the methodology here.
Author here, love the comments. The biggest criticism that makes me want to revisit and edit the article is the 2-month -> 4-month API example. I remain convinced that the Scrum process that I describe is OFTEN responsible for slowing down projects AT LEAST this much.
That said, I think I need to come up with a better example. It's honestly hard to explain in words.
Scrum is a tool. It can be used well, it can be used poorly. It is good for some situations and bad for others. The author of the article makes some good points with the key for me being Scrum isn't agile. For me Scrum is a place to start an agile transformation but it is often the wrong place to end your transformation.
87 comments
[ 2.7 ms ] story [ 2356 ms ] threadIf currently the designer is not working on the same project than the dev, they should not be in the same scrum.
Keep it short, to the point.
Scrum is not a meeting, it's an interactive tiny bite of field report.
Make it anything bigger than that, and you are not doing agile anymore.
It might well mean that you need to bring in the Product Owner to tell them the news so that together you discuss what is delivered to meet the definition of the sprint goal can be adjusted within acceptable boundaries.
If you're wondering why you should accept this definition it's because I recently attended the Scrum Patterns course run by Jim Coplien (the guy who codified the definition of the Daily Scrum and is the co-author of "A Scrum Book" with Jeff Sutherland) and heard it directly from him.
But I understand what you mean: too many people use it to track activity, not as input for the agile loop.
This is a major problem with Scrum. There's always someone telling you you're doing it wrong. If nobody's able to implement your big idea properly, maybe the problem is with the idea or how you're explaining it, not the people trying to do it.
Of course there are, and they are probably paid handsomely for their insight. How is a process that wants to implement individuals and interactions over processes and tools not a parody?
The point of separating these from actual time is not to make people feel better about themselves, it's about accounting for how much unplanned work there is in your organization which is different from org to org and even project to project.
By reflecting on how many "story points" some piece of work took, then you get better at estimating how much calendar time something will actually take.
FWIW, I've never seen this work in a team setting. I use it in an individual setting where I estimate work for myself, then gauge how much I can get done in the context of a project or org.
We were told the base principle was to have a stable team and a stable stack, and at some point we had reference tasks to calibrate our point system.
But then we had team shuffles about every 6 months ~ 1 year, so team velocity was a fantasy.
Then we changed core libraries, introduced services using new stacks, built new API, adapted to other teams’ new paradigms.
And all of these changes felt to be for the better to us. Everyone would have left if we kept everything inu place for the sake of point consistency.
Basically, how did you deal with change ?
This seems to be a failing of the author.
It's not about how many actual endpoints there are or how you actually choose to split the tasks.
Or maybe the non-functional aspects of the implementation need to be carefully considered before releasing an API that makes safety, correctness, security, or performance impossible.
Or maybe the developers have an inconsistent specification and delivering piece A now makes it logically impossible to ever deliver piece B, which is arguably more important, but got lower priority because noone took the time to understand the whole thing.
There's definitely a time and a place for Agile-derived methodologies but not every project is a nail for this particular hammer.
Also, however, most software, especially 'enterprise', doesn't actually do what it's users need, and is a nightmare for it's users. That the functionality it would deliver and how it would do so was decided by managers in advance doesn't mean it actually works for those using it.
(And note even OP concludes by saying he does like "agile", just not "scrum" -- so taneq in arguing for avoiding rapid iteration for "functionality relatively well known in advance" is not necessarily making the same evaluation as OP either).
Part of what always happens in these discussions is we all come from our experience. I've seen it work, in such a way that convinces me it was because of it's iterative nature that it worked. taneq above, I would guess, has not.
As a field, we still haven't done great at working out a methodology to extract/abstract from these differing experiences to general consensus principles, when it comes to "how we write software". So we're all just arguing from our experiences, and such arguments show that experiences really differ. Not sure what to do with that. The arguments just go round and round. I don't think attempts to make this "empirical" and "data-driven" have proven satisfactory, they often seem to suffer from artificiality/lack of validity to me too.
(And as far as personal experience -- I think most of us who have been around 10+ years find that our opinions about 'the right way to do it' change over time, as our experiences show us different things; but that doesn't necessarily mean those who have been around longer are more likely to be right and should be defered to; clearly that defering to experience rarely happens anyway).
- How do you know you need 14 endpoints? - What do they do? - Do you need them all delivered in one go? Why? - Can you make something, useful to the bulk of your users, with three or four endpoints? - Who uses the endpoints? Can they do some of their work whilst you make your endpoints? - What goes over these endpoints?
All these, and more, affect how you build and what you build. Scrum, and agile in general, should help you organise the work (where "work" includes planning, design, collaboration, as well as build and release), and gives you space to improve the quality of the work (when it's done well).
Being able to follow Scrum seems to be harder than getting work done...
I think this is similar to Pete Hodgson's clarification[1] that gitflow (which he originally documented) isn't suitable in that sort of environment. If you've got a constantly deployed set of artifacts it doesn't make sense to plan in two week blocks, and then freeze a release. In the world of software which has actual discrete releases then you either have a massive gap between releases as you get everything just right, or you say "every two weeks we'll release what's ready", and for that approach Scrum works really well.
When you're working on cloud hosted services the typical approach is more of releasing things as they're ready, possibly sitting behind feature flags or partial rollouts, and for that Kanban has worked much better in my experience. It gives more flexibility around changing priorities, and space for the inevitable production incidents and technical support that can suck up a week of time out of nowhere.
[1] https://twitter.com/ph1/status/1260702766118232065?s=21
You have a very big project to make and you know exactly what it needs to contain, examples:
1. you have an application that users already use but you need to move off a platform by a particular time or you are screwed. So you know exactly what you need to replicate in the new platform (your current functionality) and you have a set deadline to do it in. For me it was the company got sold and we needed to be off of Thomson Reuters platform within a year or pay over $100,000 a month to use it.
2. You have entered into a legally binding contract and you know what the application is going to need to contain and what you can drop without getting sued or not getting paid.
If it is your own application you can always stretch timelines out a bit to get to where you need to be, or you can decide to drop features to get to where you want to be. But once there are other people in there you might not be able to stretch timelines of drop features, and then you need something that gives you a way of alerting you beforehand if you're going off the rails.
The whole point of sprints is that requirements are allowed to change, just not more frequently than there are sprints.
Most modern scrum implementations, you release every story when you're done. The sprint is just a concept for planning what stories you're going to do in those 2 weeks, and retro.
Personally I think plans and information can change in 2 weeks, so I prefer kanban.
But at this point here isn't much between them.
The point of a methodology isn't to follow the methodology, but to use what is useful. Maybe 1 or 2 weeks per sprint isn't useful. Then maybe don't do that. Or maybe you can't estimate how much time your development might take. In that case, maybe do a little more thinking instead of presenting a black hole of time to the people that pay you. Take apart the problem until you do get a sense of how complex and/or time-consuming it might be.
Same goes for the deliverables or measurable impact; just because something has a name "an endpoint, a button, a page" doesn't mean that that defines a quantity of work or defines what you can or must deliver. Plan for what you know can be made, not for what you don't know. Having 6 months of 'planned' development seems highly unlikely to be successful, why not plan 1 month at most, and re-plan when you are near the end of the run. If people keep planning things they cannot predict it's going to keep failing.
In scrum, it is. Scrum was developed for managers to distract from the fact that they know nothing about software. So the methodology is all there is. Go ahead, ask a (non developer) scrum master about why there need to be cross functional teams, when 80% of your work never crosses the component boundary. Or go ask them who priorizes bug fixing (do this when PO, Ops, and customer care share the same room, hilarious!).
Perhaps this is a difference in where you work (the company, the culture, the country), but here a manager is just someone who has the job of making sure there are no obstructions and people have what they need and don't get shifted around too much.
Priorities are made based in input from owners, users and developers, and cross-functional teams are something that you do in a SIG, not in a development team.
Maybe SCRUM (R) as a commercial idea has a lot of things it wants you do to, but that's not really why you'd even consider something; you consider something because it might help you or clarify something for others, and for novices it can be great if you don't have the experience, skills, insight or level of thinking to come up with a self-improving process by yourself.
Then what's the point? If you cherry pick whatever you feel like, then why call it Scrum? There are people who benefit from Scrum but they are mainly not developers.
It doesn't matter how many fancy processes are named and marketed out there if they don't work for you.
The base concept of Scrum isn't any different from the base concepts of feedback loops and self-improvement; but if you call it feedback loops and self-improvement people don't really want it. That's where that marketing bs comes in, and the whole 'certified' nonsense.
You make your units of work as clear as possible, you make them small enough so you have an idea how things are going and you measure periodically to ensure you're not blindsided by human flaws all the time.
Believe it as much as you want but this estimate has a massive chance of being wrong. After that the reasoning falls apart.
Also don't assign time to points, that's completely missing the point.
Yeah, yeah. We are not true Scotsmans. In every job for last 10 years there was an implicit points -> time conversion table. And management can walk in and ask why you promise to complete a task in 1 point. It makes no sense at all.
It would be ironic to resume the article but the gist is that when rather complex reasonings get distilled into few bullet points tagged with a catchy name, then they get misused and criticised for things the original idea expressly called out.
In this case you shouldn't be promising management anything because the points only mean something in the context of a team.
Scrum in a nutshell:
1) We need to periodically check product to cut invalid activity on early stages. Let's do it in sprints with defined goals!
2) Great, now we need to complete a goal to the end of a sprint. How do we know that a team will fulfill a goal? Lets plan a sprint according to team capacity!
3) What is team capacity? It is a historic velocity metric measured in time per task in past sprints. But estimating time in time units is ... ... mambo jambo ... whatever (I did not grok what is TRUE SCRUM explanation is) ... bad, sorta. So we introduce points to estimate task size.
4) How do we estimate? Planning poker every sprint!
5) And let's add formal process to evaluate every sprint to be more serious!
It's an artificial construct to solve point 2) only. Drop a goal completion requirement and scrum will not be needed.
1) It is impossible to have specs for a complete project at the beginning. So let's ship piece by piece and accommodate spec changes as they are discovered.
2) We need at least some visibility on what to do so let's bundle a few short tasks for the (literally) foreseeable future.
3) Since we can't estimate task duration precisely because nobody ever managed to do it, let's find some measure on how much work we can get done.
4) How do we estimate this: empirically by progressive approximation.
5) This is not actually necessary.
Also I think that one of the more interesting parts of the planning poker is discussing the why a task may or may not take a long time. It can give insight into system complexity to people less familiar with a specific part of the project.
I must say though that the goal completion was more of a unicorn where I worked. We always had sprints overspill to the next one but that was not necessarily an issue.
If there is one thing I dislike about the scrum it is the rigidity which is often introduced. I think a laid back approach to it makes it more useful.
Backlog on every level is always non-empty. So sprint filling is not a problem. Planning step is not about visibility. You can have a near roadmap with any process.
But scrum tries to promise that we put only particular amount of tasks to be able to finish it. Sorta, in my experience there were only few finished sprint cases in different jobs with different teams, with and without scrum master. And from this moment scrum goes over the rails. Why we need this restriction at first place?
If they're time, you get held to it. People vaguely responsible for your rumeneration might look at ponder, "Why did it take eterm 3 days to complete that 6 hour task? He must be slacking!".
Points abstracts it away, so you don't get held to account over how long work took but instead hold the estimates to account in a fair way.
The most common sin is the standup, where each person talks for 5 minutes about something while everyone else tunes out. It's a complete waste of 30 minutes a day, made worse because you're tired of standing and just want to get back to doing things or meeting with people you actually need to meet with. I understand the theory behind it, but I haven't seen that actually happen in my entire 25 year career.
Next up is the sprint, which I've actually seen work somewhat in some companies. Generally, when they're doing it right, they'll have a "next up" lane for things that someone is serious about, in priority order, and actively maintained by the stakeholders (with an arbiter). And then the "backlog" is a black hole where things go to die (which isn't a bad thing). People grab from the "next up" lane the things they think they can get done in a sprint (keeping in mind the priorities), and off they go. That's the best case. More commonly, it's a morass of crap nobody cares about anymore, complete with questionable tasks, top-down requests (with no pipeline to discuss), or not broken down into manageable chunks.
Generally, when companies adopt "agile", there's a lot of paperwork, meetings and activity, but very little communication and accomplishment. The only worse thing I can think of is peer reviews.
I have found your problem.
If different people start at different times (the norm in tech), then there's no such thing as "first thing in the morning". You must interrupt people, which means that you should make sure it's more beneficial than the cost of interrupted flow.
This is not a reasonable argument.
As a former manager I had enormous fun tweaking and tuning the morning stand up to actually get it into a useful state. As with anything involving people there are complex dynamics, there are people who talk too much, talk too little, go off on tangents, only talk about what they want to do, don't mention blocks, insist on asking questions, Some talk too much- but only if they're the first to talk, some will always talk as much as the person before them.
It is very very difficult to get a group of engineers to have a productive stand up meeting.
Most likely because it's such an artificial construct. There are some people who will only talk when forced to. Others just won't shut up. Others try to embellish because they may not have "enough" to report at that time and don't want to look bad.
Ultimately, my experience has been that stand-up meetings slowly devolve over time into status reports, people don't listen during meetings, and if someone needs to know something, you pull them aside later talk with them (because it's almost certainly going to take longer than your stand-up allotment).
I just can't see any actual benefit to this process that was invented out of whole cloth (not to say that trying new things is bad - even invented things; rather, they should be tested and measured). What can't be measured can't be invalidated.
The key is being intentional about your process, no matter what that process is. If you can put in place strategies to solve all the problems standups are meant to solve, that's great, but the standups weren't originally designed by middle management, they were designed by engineers for a purpose.
Quite the opposite. Standup take no longer than 15 minutes, we frequently address issues which otherwise would have led to lots of rework. You need some discipline to do it right however.
Lot's of engineers are afraid to ask for help, or too proud. The standup helps people get help sooner. It also often shows where two people are actually doing the same thing, take a wrong path, help prioritize etc. I can't imagine a software project without a standup anymore.
It's funny, if I would pick out the two single most valuable things out of agile I would say standup and peer review.
I've never seen what you describe actually happen (although I know that this is the theory behind it).
TBH I haven't really noticed much difference in the accomplishments of scrum and non-scrum teams.
lol. too true.
It's also great at taking great developers and turning them into average developers.
Everyone just wants to take something easy off the board that you can get done in a day so you have something to report in tomorrows daily scrum. It's just everyone trying to pick the low hanging fruit. THere's no incentive to be smart and to take time to think about solutions, if nothing is moving across what are you even doing? You're letting the team down! The velocity is falling!
I think if you have hard problems to solve you solve them by giving them to smart people then leaving them the fuck alone. You don't constantly harras them everyday demanding to know what they did yesterday and what they plan to do today. With daily updates where is the incentive for the smart people to work on the hard problems? They now have the same incentive as the junior developer, find the easiest tickets to move across the board.
Sometimes I will want to just be alone and think about a solution for a few days. If I do that though I'd have nothing to say at the scrum. So instead I'll pick the user story where the colour on a front end was the wrong shade of green or a spelling mistake! See, I knocked out 2 stories in one day, before lunch! Go me!
And it all looks like progress because stupid cards are moving across a pointless board.
Scrum exists because managers don't trust developers to get things done without constant supervision and an ever present threat of looking bad for your team.
It takes a team of potentially really smart people and turns them into a code production line. It's depressing.
But that only works when management is willing to say “this ticket will be on the board for a while and that’s okay, we won’t harass you about it.” That is, scrum is decent for organization but bad for management.
A good tipoff is how long standup lasts. It should be no longer than 15 minutes for a team of six, and that’s stretching it. Aim for 1-2 minutes of talking. That’s more than enough to say “I worked on tickets X and Y, I’m stuck on A and making good progress on B.”
That's really the key a lot of development orgs miss. You have to actually break down the work into smaller pieces and track progress on those pieces. "This feature will take 3 months to do. I will start now and three months later, a working feature will pop out of the black box." - will give most Project Managers a heart attack. "This feature will take 3 months to do. I'll take a few days to break it down into approximately 1-week sized milestones and throughout development we can talk about progress vs. those milestones." - ahhh, that's much better!
Given the available pool of poor/average/great developers, this may be the correct decision.
Model: There are a1, a2, a3 developers of poor/average/quality. Poor developers cost p1, have a default productivity of q1. Average developers cost and produce p2, q2 and great developers cost, produce p3, q3. Scrum brings everyone's productivity to q2. Note that no one gets a raise or pay cut.
Without Scrum your total payoff is
With Scrum it becomes So what you need from Scrum to be worthwhile is that i.e. Now, let's say 60% of programmers are poor; a1/a3 is 1.5. So even if poor developers improve by 1/3 while great developers are downgraded by 1, we're better off.Reminds me of https://youtu.be/VAAOnmOlrLU?t=155
Of course star developers hate Scrum. But star developer code is often crummy too, and technology advances so fast that I'm glad for every dollar I didn't pay for divine Win32 code.
Ye... No. Note that your made-up productivity algebra model crumbles as soon as you stop seeing developers as code churning machine and instead as what they should be, problem solvers. That's because quantity is not the only metric by which you can measure problems. Complexity and ease are others. A dozen average problems do not necessarily equate a single hard one. Hard problems can prove elusive to average devs and they're usually where you see materialize the limitations of the thinking that a single great developer can simply be replaced with a dozen average ones. One such manifestation is commonly called "technical debt".
I've run into situations recently where the work that nobody wants to do never gets done. Even experienced engineers fall into the trap of only wanting to work on interesting features and nobody wants to do the "needs to be done" shit work.
The deadline rapidly approaches, the senior engineers are working on whatever they want to work on and it's the dev lead who stays up late and gets done what needs to be done before the deadline. Lather, rinse and repeat for a few releases and you realize why even good managers fall to the temptation of micromanagement.
it's not that they don't trust them, it's that they don't get things done without constant supervision.
> potentially really smart people
potential is not actual. in actuality, most of your coworkers are decidedly average. and the average coder, like the average driver, isn't that great.
the solution for smart people (who also produce), is to not work at these places. easy.
i say this having only worked at 2 places that do scrum. both of those places had only enough superstars to count on one hand, and the rest of the staff were dullards. yet, they got things done, thanks to the micromanagement of scrum. i didn't participate in the scrum, because f' that.
In my team, we are just able to take the S cards, when the L cards are done. If a Junior get a L card, a senior will come and pair with him/her. Nobody tries to be clever, we all try to move forward together. As a Team.
What is your Scrum Master doing?
I've always felt that most companies do "scrums" wrong. It's not supposed to be an hour-long status report; it's supposed to be a 15-minute check-in to identify blockers and connect people so those issues can be addressed outside of the scrum. A good scrummaster should be able to clamp down on the "status report" aspect of it, but it's really hard to find a good scrummaster since it's largely seen/compensated as an entry-level position.
When the alternative is a near certainty miss of waterfall and tremendous, tremendous cost overages, then scrum starts to look like the less ugly dance partner.
Consistent challenges I see for anti-Scrum arguments:
1) Their POs are doing a horrible job defining what an MVP is, or the devs aren't following good MVP practices. The MVP solution as something that works outside of Scrum is well proven in numerous other contexts, regardless of what a developer designing an API may think.
2) Their Scrum Masters are allowed to turn into managers, not process governors. The silly SM metrics SMs start to make to increase their job justification suddenly govern teams and paychecks.
3) Their management doesn't understand what POs and SMs are really supposed to do.
4) Ok, present an alternative to Scrum, waterfall, in a way that works with financial reporting and accountability to the people that pay the bills and paychecks. This is the major sticking point. Criticize Scrum :thumbsup: Come up with an alternative that meshes with the reality of software the profit-seeking business :silence:.
The problem is management. Tools (burn down charts) now become executive metrics. Amount of code completed now becomes a review item for advancement. We've applied measures to things that are inappropriate for what they are used for, and because of this honest communication has been replaced with guarded statements to make sure that the team never stumbles with its work. No matter what process an organization uses in those places will fail, because management wants to hear things are running fine.
Yet again, here goes.
- The problem here is dogmatism, both yours and whoever is "doing scrum" to you. There is no Scotsman! He ran away. That is, it's only if you're insisting whether you're doing it right or wrong can you start to have the conversation about what is right or wrong. Your premise is invalid.
- Confusion over terms. These things are much better represented mentally by the image of a bookstore. You arrive at a bookstore and want to read up on some stuff related to teams and planning. Cool! There's a scrum section, just next to the agile section. Guess what? The books don't all agree with one another, and that's fine. It's a marketing term, a place to go for ideas.
It gets worse after that, with dysfunctions of estimating and so forth, but you start out with your head in the wrong place, whether you love X or hate X, it's not going to end well. Do stuff you like, make stuff people want, and get stuff done. If that's not working for you, here's some titles of sections in the bookstore where you might want to read some other stuff. There are other sections. If you find some sections that have cool stuff, let me know. I might could learn some neat stuff I might use one day.
That's it. It's nothing more complicated than that. You can go to those sections and learn a whole bunch of stuff about various problems you might have. Try some if you like. Or not. What you can't do is go to that section and pull some book out as if it were a recipe and then "implement" it on a team or organization. It doesn't work like that, and it's never going to work like that, whether your view is from the top or bottom of an org. You're doing it backwards. It hurts when you do that? Ok. So stop doing it that way.
That said, lets clear up some misinformation:
1) Scrum is vague? It said it right there: "Scrum is a framework" - Scrum is NOT a process, technique, or definitive method.
2) On delivery windows - "I’m not against management being informed… but at what cost?". Scrum works well for businesses/departments that have a development need, not where the business IS development. It needs to fit into the business, not vice versa, and that means managing stakeholder expectations.
3) On scrum managers - "let the lead developers handle the job." Of course! Or your development team manager, depending on your org setup. The roles in scrum are ROLES - not a new org structure.
4) Estimates - sure, points are stupid. They literally make no sense. They aren't prescribed by scrum in any way, shape, or form. There is nothing wrong with using time as an estimate. Period.
I think the target audience of Scrum could be made a LOT more clear. It would save a lot of heartache and hate. I think successful marketing and certification have become the chief enemy of Scrum - orgs have tried to shoehorn it in everywhere, and thats not what it is for.
The way I get the most stuff done is meeting with the rest of my team every two weeks to:
- Look at what stuff needs to be done next, based on the stuff we want to do, stuff that other people want us to do, and stuff we don't want to do but need to do anyway
- Figure out between us how much work is involved in doing that stuff
- Review how much stuff we did in the last two weeks to see if we did what we expected to
- Use that information to agree between us how much of that stuff we think we can do in the next two weeks
- Make sure that we have all of the information and prerequisites to do that stuff
- Based on all that, to estimate how long all the stuff will take, pick which stuff that we expect to be able to reasonably do, and prioritise what's most important
Then every day, we check in for 10 minutes to see if there are any problems doing the stuff, if unexpected stuff needs to be done urgently, or if we want to show the stuff to anyone else.
Once every two weeks, we show everyone else what stuff we did and answer any questions about it; once every couple of months, we all sit down together with other people, look at our list of stuff that we want to do over the next six months, make sure we all agree on what the plans are over that timeframe, and make any adjustments we think we need to.
Someone is in charge of making sure that all those things happen, that everyone has what they need to do their stuff, and that everyone outside the team knows what stuff is being done.
This is just Scrum using words that don't piss engineers off to the same extent. Scrum is nothing particularly special or magic – it just provides a basic set of tools and terms to describe a bunch of interactions and help keep them on track, and they are for the most part pretty reasonably tools.
And here's the reason this is not a good article – it makes the same basic mistake as many others do and assumes that a development framework is somehow supposed to magically fix your broken team. A bad manager is a bad manager, regardless of whether you call them a "scrum master" or something else.
But hey, it's HN, so I'm sure there will be absolutely no other positive comments about the methodology here.