DEV Community: Dustin Robison

Agile Scrum: this is (rarely) the way

Dustin Robison — Mon, 27 Sep 2021 21:22:32 +0000

Agile Scrum is composed of many assumptions and rituals that don't apply to most software developers or their teams. Scrum has become the standard process for organizing development mostly because it makes great promises. However, only certain situations will actually deliver on those promises.

Agile Scrum Promises simplified:

The business decision makers are promised:

Planning and schedule predictability
Increased output and visibility from developers

The developer is promised:

A continuous sustainable pace (ie. good work life balance)
More innovation, learning opportunities and rapid change
Increased morale

Does Agile Scrum deliver on these promises?

Rarely, in my experience and observations. I was fully sold on Agile Scrum in 2013 when an external company came and trained most of my company over a 3 day period. Since then I have been a part of and witnessed team after team falling into the productivity decline of "Storming, Forming, Norming" that Scrum adopters are warned about but have not witnessed any team come out the other side of "performing" with great productivity.

Why has Agile Scrum failed?

Assumptions. Agile Scrum makes many assumptions of a team's shape and composition that have rarely been correct. These assumptions are not posted anywhere to my knowledge but seem to be in between the lines.

Assumptions:

All team members are equally capable of doing and estimating all team work
- Developers can become experts about everything technical
- Developers have some authority in technology and commitments

Agile Scrum asks each and every developer to weigh in on task complexity for estimation purposes even though most developers gravitate towards a certain domain area or technical stack area and others are clueless about it. Ideally it would be nice if each developer could contribute well in each area but in my experience that just doesn't happen.

Development and business have equal priority decision authority
- Development team must have a large quantity of reserved capacity for non feature tasks

Normally, business feature requests consume the entire development team workload. A business area wants a massive workload of epic tasks done in a quarter that they trim that down to about 10% of the tasks to ask the development team. Likewise, the development team should have their own massive workload of automating things and technical debt that is then trimmed down to the most important 10%. Well, what happens next? The business team explains that their 10% tasks are business critical and the development team complains that they would be stretched to do half of the request work. The development team's requested workload is forgotten, technical debt is layered with more technical debt and team productivity and morale is broken.

A team shares authority and responsibility equally

An individual developer is no longer responsible for almost anything in Scrum, everything is the team's responsibility. In theory it sounds like a great new union has formed but in practice I have often seen that leads to developers' motives changing to hit their story (imaginary) point numbers instead of delivering value to the customer. The developers who are highly invested in their product and customer are often viewed the same as everyone else on the team.

When scrum gets ugly

At its worst I have seen scrum practices used for non productive intentions. I have seen Scrum be used as a means of micromanagement so a leader can be in everybody's business and determine how they work and should think. I have seen multi-day sprint ritual meetings that ignore immediate customers' needs. I have seen Agile Scrum be subverted for someone to take leadership authority in order to get control of projects and their technical decisions. Instead of a technical lead working with interested parties a scrum master will step in to talk about MVP (minimum viable product) and tell everyone to prioritize creating technical debt. Of course these aren't always the case but I have seen this and more multiple times in the past 8 years.

The Rituals

Lastly, Agile Scrum preaches a lot of meetings. Daily Standup, Backlog Grooming, Sprint Planning, Sprint Review, and Retrospective. Most of the meetings are about planning work and staying in sync with the rest of the team. This sounds really good on the surface but for most developers it really doesn't matter what a different group of developers are doing and it is more time wasted in meetings.

If not Agile Scrum then what?

I don't know. Personally I liked Kanban's simplicity, prioritizing tasks and getting them done. There are trade offs with each option but Agile Scrum seems to be on a Corporate Bible. Hopefully more businesses can start thinking of better options.

Conclusion

I don't actually hate scrum, in fact I am part of it every day and my team does a good job making it as lean and quick as possible. I do hate that scrum is the only choice in corporate software environments these days. I personally value the freedom of development choices and ownership of responsibility over the ritualistic meetings and all developers are equal mentality that Agile Scrum promotes. I have yet to see an Agile Scrum team leave their "Storming, Forming, Norming" productivity dip in 8 years and I hope we can find better solutions in the future.

All my posts are based off my personal experience and I would like to hear if you have had a different experience or comments

Thank you for reading! My blog: corpcoder.dev

How to handle working on something you do not like

Dustin Robison — Fri, 24 Sep 2021 17:57:47 +0000

The Problem

A corporate coders true dilemma: being told what to build and how to build it.

Every corporation has non software developer leaders that often are making technical choices. In an ideal corporation the business leadership would focus on what they want and leave it to the technical team to resolve how to build it. Some negotiation would take place over timelines and features but the end decision would result in the business choosing a product and the technical staff choosing a method of creating the product.

I personally have been on the receiving end of being told how to build things by non technical people multiple times in almost every corporate job. It is more common at larger companies but also happens at smaller companies as well. At one large company we were told to use a tool that really did not fit our use case but it had a large price tag and great presentation with big promises. At another large corporation a developer pitched an idea of a way to build things with "no code" and had leadership sign off creating a large complexity headache for all other developers. At a small corporation I worked on a valuable new piece of software that was shut down by an executive because he only wanted to pay for "the standard approach." The developer subsequently left and created a successful startup.

What is important to you?

This is the real question: what is important to you? Or really, what is the relative importance of how you are working vs other concerns?

How important are those paychecks, benefits and stability to you?
How important is your pride of craftsmanship?
How important is your corporation or business units mission?
How important is your company position?
How important is your geographic location?
How important is your career path?
What are the other important factors?

The common case: a job is just a job

For most people a job is just a job. In my opinion these people aren't wrong at all, in fact they may be the most correct. If you can be satisfied making your objection about the poor methodology choice but still work hard as normal then that is great. You must still be achieving the things that are important to you and in the end you will likely produce a good product.

There are risks with this of course. Corporations have no guaranteed commitment to their employees (or vise versa) so if suddenly you are out of a job then your options may be more limited.

The noticed path: my way or the highway

For some people the work that they do defines them and doing anything less than their optimal solution would directly lower their self worth and positive impact they can have on the world. This is a hardline dangerous road however many great new corporations have come from this. I don't recommend this path because I think there is a slightly better option that I will discuss next but if your current job is bad for your mental or emotional health and you can't take it anymore then perhaps this is your only true option.

If you think this is the path for you I would encourage you to take a step back and breathe and really consider what is important to you. What motivates you? Maybe a paycheck, benefits and stability are not important factors for you but they are sure are nice to have and it is extremely risky to drop a job without even a career plan.

There are also ways to mitigate the negative emotions of working on something you do not like that I will discuss at the end.

The patient path: the grass is always greener

Everybody has heard the adage, "never quit a job until you have another one." It is great advice but also lacking. If you don't like your current responsibilities will taking a new role be better? Maybe, or it could be worse. As corporate coders we have to understand that we surrender most of our power to decide how we go about our work by taking a paycheck. Our primary clients are often our superiors, the person paying you; not necessarily the end users of our software. Your primary customer is always right.

I encourage software developers to be patient and find out what is important and motivates them. The answer is often different than we would first think and if you do not know, then that is okay too. If you have served enough time to make your resume look good in your current role then patiently try looking for a position that you think may suit you better and learn from each role. Make friends with your coworkers to open new opportunities and get their input as well.

A simple mitigation strategy

If you are unhappy that you do not get to do the work you want to do then a simple answer would be to do the work you want to do in addition to the work you must do. Discuss with your manager if you can spend some of your work time on a new idea or just simply work on your own project outside of your work hours.

For example, if your job has you working in Python but you like working in JavaScript then do your Python during work hours and do JavaScript at home. To get a job doing JavaScript you will definitely need current experience and probably a portfolio. Learning and doing more will lead to greater opportunities.

Conclusion

Find what motivates you and what is important to you through experience, patience and perseverance. Once you know that you can be happier in your current role or you can decide how you are going to achieve your goals.

All my posts are based off my personal experience and I would like to hear if you have had a different experience or comments

Thank you for reading! My blog: corpcoder.dev