Scrum Master uses random number generator to assign task numbers to the sprint. Is this how Agile software development normally works?

Question

I’m a junior just a few months into my first software dev job after graduating. We are three sprints into our new project and they management decided to use Scrum as it’s “a fresh approach.” To “keep things agile”, the scrum master is using a random number generator to choose tasks to do during sprint planning. It is apparently called “planning gambling.”

We use React and Django, so front end and backend tasks a separate. The “planning gambling” has resulted in all sorts of frontend parts without backend and all sorts of backend stuff that doesn’t do anything.

They also embraced wholeheartedly the agile philosophy of not spending time documenting anything, so developers are making all the decisions beyond the one sentence of functionality they give us in the tasks. Fine if the devs were building the complete component (as we have reviews/demos), but problematic when they components need to talk in some random task assigned later and the components are not fully built.

The project is moving slow as a lot of time is spent guessing at the actual needs of the component, upper management complains about the lack of progress on specific pieces (and blames our tech lead, not the scrum master, who says it is waterfall management to choose one component over another), and we spend a ton of time redoing work because the product owner and scrum master do all of a sentence of thinking before they send devs off to code and hope they guessed the goal of the component correctly.

Is this what software development is like normally? As I don’t think this career is for me anymore...

Answer 1

Wow, there's a lot in this. Let's start with the easy one:

Agile absolutely does not encourage no documentation.

The Agile Manifesto says it values working software over comprehensive documentation. If you read anything by one of the people involved in the crafting of that statement, the clear meaning is that documenting what software you will build is not the same as building it. If you have a stack of design docs and no software, you still have no software. This is used to support short batches where you design and document as you go in small batches instead of having a large design and document phase followed by an implementation phase. For teams practicing Scrum, it is common to have an item in the Definition of Done for completing all needed documentation, meaning that work isn't done until all documentation for that functionality is finished.

No Front-End / Back-End

Ok, obviously, from an architectural point of view there is a front-end and back-end. From the customer's point of view, these are non-sense words. This means that items in your backlog should encompass the whole feature. For example, I should have a backlog item that reads:

As a registered user, I'd like to be able to update the email address on my account so I can get emails at my new address.

This item would be done when both back-end and front-end are complete. Further, the dev team is responsible for figuring out the best approach to that item. Levels of sharing, cross-training, and co-ordination are strictly under their discretion. The exact line form the Scrum Guide is:

[The development team is] self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

The only way I can imagine that what your Scrum Master is doing is a good idea:

There are time, as a scrum master or coach, that I have advised the team to do something that was a bad way of developing software. These was usually for a short period of time in order to gain some other learning as a team. I was clear with the team about what I was trying to accomplish and had their buy-in. If I cast your story in the best possible light, this could be a learning exercise that they should have gotten the team's buy-in for first. I could see how randomly selecting tasks would force the team to closely coordinate and create shared code-ownership if the exercise was executed well. Without your buy-in, however, I can't see it having the desired effect.

My Advice

I would have a sit-down with the Scrum Master and ask them to explain what they are trying to accomplish. They are probably genuinely trying to help. Appreciate them for it, then explain the real impact they are having. In the end, maybe you do it in a different way that gets the learning they are seeking without causing chaos. Maybe you try something different. Maybe you drop it entirely. In the end, you (the dev team) should always be able to assert your right to decide how to build the increment yourselves. A warning though, don't make it a rules-lawyering process. Use the scrum guide for guidance, but it isn't written in stone.

For convenience, here's a link to the online version. It's a short 16 pages. The Scrum Guide

Answer 2

Is that normal? No.

That’s not agile nor scrum....not even close. That’s madness.

There’s an agile concept called planning poker but it revolves around task size estimation... individuals using playing cards to indicate their estimate the task size. This prevents members from influencing other members on task size estimates, it also brings up conflicting/missed assumptions when estimates are too far apart.

Product owners should prioritize tasks/features... not RNGs. Task/feature dependencies should have been identified before items are prioritized.

As far as documentation goes, there is nothing in agile that says “No documentation”... so it looks like someone misunderstood the agile manifesto, or added a personal (misguided) twist to it.

Answer 3

Is this what software development is like normally? As I don’t think this career is for me anymore...

There are a lot of companies that say they're doing Agile and Scrum. Take it with a pinch of salt. Read up on Agile and Scrum. They're surprisingly short texts:

The Agile Manifesto

The Scrum Guide (2017)

the scrum master is using a random number generator to choose tasks to do during sprint planning. It is apparently called “planning gambling.”

A common practice in Scrum is "planning poker", which is used when the developers are estimating how long a particular story would take to implement. Each of them has a set of numbered cards (commonly numbered 1, 2, 3, 5, 8, 13, 21) and they all pick a card that they think matches the difficulty. If the developers are all showing very different cards, it's a sign the developers aren't really in agreement on what they're being asked to do. In that case, the story probably needs to be explained better. So the whole purpose of planning poker is to reduce uncertainty. Not gambling.

Choosing random tasks is in fact very much counter to the Scrum philosophy, where each sprint should have a clear overall goal. The developers then choose stories from the backlog to work on, that will help fulfill that goal.

Finally, this really doesn't look like a Scrum Master doing his job right. The Scrum Master is not a joker/project manager. He coaches the developers and product owner in using the Scrum process effectively.

They also embraced wholeheartedly the agile philosophy of not spending time documenting anything

This is not Agile philosophy. Literally, the Agile Manifesto states:

"Working software over comprehensive documentation"

(...)

"That is, while there is value in the items on the right, we value the items on the left more."

The project is moving slow as a lot of time is spent guessing at the actual needs of the component

This goes very strongly against the whole idea of Scrum, which is that you're always working on something that will clearly add value. You don't go build anything in Scrum until you know what it's for.

---

It sounds a lot like your Scrum Master read the title of a slide deck about Scrum, but nothing else. It's really unusual that it's quite as ridiculous as what you describe. I'd like to close with a quote from the Scrum guide:

End Note

Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although 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.

Answer 4

Is this what software development is like normally?

It can be, in the worst sort of waterfall companies, where you follow a rigid plan and ignore whether it's actually working until the end. It sounds like your company has managed to recreate the problems of waterfall by throwing out the (supposed) benefits!

The point of agile development is that you regularly look at how things are going, and change your plan and processes until they work for you. Sticking rigidly to someone else's process is the opposite of agile, even if they labelled it 'Agile'.

Remind everyone that part of Scrum is Retrospectives. Sit down and talk about what is working and what isn't, and learn from experience. You might be reinventing the wheel, but that's better than trying to use square wheels because you think all the cool people are doing it.

Answer 5

You're generalizing based on one experience, and I think you know better.

Sounds like that place is simply a madhouse, and that you need to start looking for a job that will allow you to learn, and grow in a more structured environment. The more experience you have, the more you will be able to cope with less structure, and more responsibility. When you're relatively new, however, this will be detrimental to your professional growth.

Your leadership is mangling the methodologies, and simply playing buzzword bingo. The whole operation will suffer tremendously sooner, rather than later (technical debt is a thing).

Answer 6

Okay, so I want to jump in that I have never come across the idea of choosing tasks randomly - that seems counter productive to actually getting things live.

But all in all I've also not really seen any workplace do "Agile" in remotely the same way as other places so who knows. But also Agile isn't something about a "lack of documentation" ... keeping well documented software is one of the key aspects of making Agile work, so your software should be documented.

Of the places I have seen working though documentation is often pretty damn lacking, and it makes picking up projects from someone else a nightmare. This part is a regular thing in software development, but you can help by actually writing docs for things you pick up (there are also tools for auto generating docs all over the place).

But yeah, the "Planning Gambling" is not something that I have come across, and would probably be pretty strongly against unless someone could give me a pretty slid list of reasons to why it would be beneficial, so this part as least is not exactly typical of workplaces.

tl;dr Agile gets done very differently in different companies "Planning Gambling" is something I've never seen before, but lack of docs is often fairly common from experience.