107

I'm a web developer working in a team of three developers and one designer. It's now about five months that we've implemented the agile scrum software development methodology. But I have a weird feeling I just wanted to share in this site.

One important factor in human life is decision-making process. However, there is a big difference in decisions you make. Some decisions are just the outcome of an internal or external force, while other decisions are completely based on your free will, and some decisions are simply something in between. The more freedom you have in making decisions, the more self-driven your work would become. This seems to be a rule. Because we tend to shape our lives ourselves.

There is a big difference between you deciding what to do, or being told what to do.

Before scrum, I felt like having more freedom in making the decisions which were related to development, analysis, prioritizing implementation, etc. I had more feeling like I'm deciding what I'm doing.

However, due to the scrum methodology, now many decisions simply come from the product owner. He prioritizes PBIs, he analyzes how the software should work, even sometimes how the UI and functionality should be implemented. I know that this is part of the scrum methodology, and I also know that this may result in better sales of product in future. However, I now feel like I'm always getting told to do something, instead of deciding to do something. This syndrome now has made me more passive towards the work.

  1. I tend to search less to find a better solution, approach, or technique
  2. I don't wake up in the morning expecting to get to an enjoyable work. Rather, I feel like being forced to work in order to live
  3. I have more hunger to work on my own hobby projects after work
  4. I won't push the team anymore to get to the higher technological levels
  5. I spend more time now on dinner, or tea-times and have less enthusiasm to get back to work
  6. I'm now willing more for the work to finish sooner, so that I can get home

The big problem is, I see and diagnose this behavior in my colleagues too. Is it the outcome of scrum? Does scrum really makes the development team feel like they have no part in forming the overall software, thus making the passive to the project? How can I overcome this feeling?

yannis
  • 39,547
  • 40
  • 183
  • 216
Saeed Neamati
  • 18,142
  • 23
  • 87
  • 125
  • 4
    Are you sure you weren't just committing yourself dysfunctionally much before? – Donal Fellows Aug 16 '11 at 10:28
  • 27
    Nice blog post. – Robert S. Aug 16 '11 at 13:25
  • 20
    what you are describing isn't SCRUM –  Aug 16 '11 at 13:36
  • I seriously do not get this perception that you need to feel a certian way to program. You sound like you have a motivation problem stemming from a case of you perfer to program how you want to program not the way some idiot tells me. It is a job. You have 3 basic choices: Go find a job that will let you program how you want, Adapt to the new system and what it does for the end product, continue as is. To your employer it is the end result that matters most(Along with the cost). If it is effective they are unlikely to change. – SoylentGray Aug 16 '11 at 15:16
  • 5
    @Chad. What I discussed here is not a complaint of my work situation. I just wonder if this mood is the result of scrum? And whether other developers are also experiencing the same thing or not? – Saeed Neamati Aug 17 '11 at 04:55
  • 5
    @Saeed - Sorry to be blunt but your mood is the result of your decision on how to deal with your work environment. It may be affected by others opinions and attitudes as well but you could also choose to embrace this method. It absolves you of the need to be responsible for design decisions and lets you just work at solving specific problems. It doesnt sap all of your energy and allows you to work on more of your home projects. You have more time to develop you. These are not bad things. It is not your employers job to make you happy. You can find another job or you can accept this. – SoylentGray Aug 17 '11 at 13:03
  • 1
    Couldn't your feelings of lacking control over the destiny of the product stem from the fact that the product is now more mature (hence the need for Scrum meetings) and the development cycle is further along, rather than the meetings themselves? – Jared Updike Aug 18 '11 at 19:23
  • 1
    I'm not sure how #3 (having more time, energy, and desire to work on your own after-hours projects) is supposed to be a problem. – Dave Sherohman Aug 24 '11 at 11:00
  • 4
    @SaeedNeamati ignore chad's comments. They're borderline abusive to you. It sounds to me like your product owner is overstepping his boundaries. A lot of the things you talk about should be defered until you're ready to implement the stories. – Dave Hillier Jul 26 '13 at 14:20
  • 1
    The guru Erik Meijer would agree with you: *"Stand-up meetings in Scrum (a common Agile approach) are an annoying interruption at best, or at worst one of the mechanisms of “subtle control”, where managers drive a team while giving the illusion of shared leadership. “We should end Scrum and Agile,” he says. “We are developers. We write code.”"* http://www.theregister.co.uk/2015/01/08/erik_meijer_agile_is_a_cancer_we_have_to_eliminate_from_the_industry/ – lbalazscs Feb 17 '15 at 00:57
  • 1
    You are not alone. Every Scrum/Agile Situation, I have found myself in, in the last 5 years have left me feeling exactly the same way you feel. I am a consultant.... I get to wave bye-bye to many of these projects only so many months, some as soon as I can find a new gig. I can only imagine how the full-timers can cope with being on such projects for so long. You can tell with some as the problem-solving "rush"/excitement of being a programmer is slowly drained away after only a couple of months, some end up going completely numb after a year or two. – user272671 Mar 25 '16 at 15:48
  • 1
    Scrum is often just an excuse to implement horrible micromanagement. Scrum shops are often turning into a user-story-punch-card-processing workshop. It absolutely kills innovation. I liked many aspects of Scrum a few years ago, but after I've experienced how badly and horrifyingly can it be applied, I'd never recommend the scrum hell to any organization who is trying to employ smart, creative engineers, instead of a horde of obedient, rule-following punch-card-processing bio-robots. – Tamas Kalman May 08 '16 at 00:34
  • Now there is a survey out there to analyze these sentiments: https://www.surveymonkey.com/r/JLF6D25 – Sampada Jan 31 '17 at 09:19
  • I was amazed by Saeed description as i feel like i have written it. – OrPaz Oct 11 '18 at 11:58
  • 2
    I was amazed by Saeed description as I feel like I have written it myself. I am an experienced developer and over 20 years, and for me it is obvious Scrum is a bad fashion. A post Trauma of waterfall. It discourages every piece of creativity that you may have in you. It puts developers in the worst position they could be in - a shallow text writers that could be switched and replaced without any problem. It is only a matter of time this fashion will pass as people will grasp that scrum inventors just wanted to create a failsafe system for managers with the price of sacrificing the developers – OrPaz Oct 11 '18 at 12:06

17 Answers17

65

Your problem is not Scrum (and as Jarrod Roberson mentioned in comments, it is not Scrum what you're describing) - it's Product Owner's micromanagement and your (and Team's) lack of assertiveness.

"However, due to scrum methodology, now many decisions simply come from product owner. He prioritizes PBIs, he analyzes how software should work, even sometimes how UI and functionality should be implemented. I know that this is part of scrum methodology."

You're mistaken. Just from a brief look at wikipedia page for Scrum one can see that: "the Team, a cross-functional group who do the actual analysis, design, implementation, testing, etc." See? Product Owner tells you what to do, but it's up to the Team to decide how to do that.

You are the person responsible for implementation, so you should decide how the application is going to be implemented. Listen to the Product Owner's opinion, but the final decision is up to you (or the Team).

BTW micromanagement does turn active developers into passive developers.

Lukas Stejskal
  • 1,404
  • 1
  • 10
  • 15
  • 39
    Amen to that last line – Wivani Aug 16 '11 at 14:33
  • 6
    "Product Owner tells you what to do, but it's up to the Team to decide how to do that." That's exactly what can be a problem for devs motivation: lack of innovation. Most of the time customer will want faster horses, not cars. But I absolutely agree with micromanagement. – MaR Aug 16 '11 at 19:11
  • 1
    +1 @Lukas, because of the differentiation between **what** and **how**. Thanks buddy. – Saeed Neamati Aug 17 '11 at 07:56
  • 5
    "Product Owner tells you what to do" - I don't quite agree with that. They ought to tell you what they _need_. A slight but important difference. In other words: they describe the problem/issue, you provide the solution. – DanMan May 03 '14 at 21:16
  • 2
    @MaR That's why the devs don't talk to the customers. The customers talk to the Product Owner and ask for faster horses, the P.O. is the one that sees all the clients' issues, combines and prioritized them, and in the process figures out that cars are better than faster horses – Izkata Jun 27 '14 at 12:31
50

However, I now feel like I'm always getting told to do something, instead of deciding to do something.

This is a serious indicator that something has gone off the rails. An agile project should not feel like this. That "people over process" rhetoric should include "we don't force our people to do things that suck." Here are some ideas:

Are you doing "scrum but"? That is, part scrum, part some other thing. (ie: "We're doing scrum, but all our stories have to come from our PMO, not a product owner.") Lots of crazy crap is called Scrum these days.

Are you, personally, not involved in the process where you should be? I've known a number of people to be upset at the contents of stories, and it turns out that they only get involved once the story is in the sprint backlog. Talk with the product owner early on in the development of the story, and get your feedback in. (As the PO, they have the final say, but that doesn't mean they have to do it alone.)

In Scrum, the team is supposed to own the process, and it's expected that the process will change over time to suit the team's needs. Bring up your concerns at the retrospective. If you can come up with a process tweak to suggest, that tends to make it easier to sell for some teams.

ChrisF
  • 38,878
  • 11
  • 125
  • 168
Sean McMillan
  • 5,075
  • 25
  • 26
  • 10
    +1 Scrum (as all Agile methodologies) be heavier on conversation than direction. The PO should be describing what the end result needs to be able to accomplish, then engaging the designers and developers on ways to get there. – StevenV Aug 16 '11 at 12:17
  • 6
    "people over process": Funny, then why impose the SCRUM process instead of letting people use their own? And why all those measures (pair programming, frequent progress reviews) that, in the name of transparency, allow to monitor the work of developers much more closely? – Giorgio Jun 27 '14 at 04:56
  • 3
    @Giorgio: Because structured development enables teams to work together without stepping on each other's toes all the time. We just haven't figured out how to do it perfectly yet. – Phoshi Jun 27 '14 at 08:16
  • 3
    @Giogio, this is an issue with agile in general. Though a goal is to have people over process, in reality Agile becomes religiously followed - which again puts process over people. Personally I think lean does a better job of this than agile, though it does not attempt to enforce a strictly horizontal structure of the team - it does allow developers to choose tasks better. Assuming your team won't change, a kanban board in addition to what you are doing now could make management happy and you happy as well, giving you freedom to choose your stories/tasks. – Jono Nov 07 '14 at 02:32
28

What you are describing is NOT SCRUM

Your product owner is over stepping his bounds if he is telling you how to do your job technically, that isn't what SCRUM is about at all.

SCRUM is about freeing the developers to concentrate on development issues and empowering them take charge of determining how long things take and how to do them.

SCRUM is about collaboration, that is what Sprint planning meetings are for, to promote collaboration between all the stake holders; product owner, developers and testing.

Yes the product owner should prioritize features, what needs to be delivered first according to the customers needs, but the developers should be doing the engineering and design, not the product owner.

I don't agree that developers should be designing GUI's and workflows unless they are specifically tasked and trained to work with the customers and hash the functionality out with the customers directly. Programmer built GUI's done in a vacuum rarely meet customers needs.

SCRUM is about putting a light weight process that can be predictable and repeatable over the agile manifesto.

It makes me sad to hear stories that very good things are being perverted like this.

  • 3
    Human nature will always find a way to snatch defeat from the jaws of victory. – Warren P Oct 17 '13 at 01:54
  • 3
    There's what SCRUM is _supposed_ to be, and there's what it _ends up being_, at least at most companies. SCRUM isn't evil in and of itself, but it's a tool that is very easily used for evil by management. – AresAvatar Apr 07 '15 at 00:33
11

It sounds like your adventures into Agile have been corrupted by Scrum. I find that, of all the agile methodologies, Scrum is the least agile. Its more like miniature waterfalls and additional project management. This, of course, makes it the most liked by management who feel them are taking control back from those pesky developers, but of course you see the reality of the situation.

Agile is not about following a prescribed path, it is designed to make you more productive and motivated. People not processes says the manifesto (paraphrased), and that's lost in the system you're using.

So change it. Bring it up with the management and say that it is a retrograde step, that your productivity is less than it used to be and you're all unhappy with the way its working out. Show the Agile Manifesto (and its evil twin) and demonstrate that you've not only learned lessons from this experiment but want to evolve the good bits from it into a better system (one that's like you used to have, which appears to work well for you).

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • have you ever felt this way, because of agile? – Saeed Neamati Aug 16 '11 at 10:44
  • 7
    me? yes - we used to work well, then management decided that Agile was the future, and imposed scrum, which restricted us tremendously. What we used to do effortlessly became bogged down in process and bureaucracy. I once took 3 cards from the scrum board!! The lights flashed and the sirens wailed for this breach of 'the scrum way', and I once took the card *back to my desk*. The project management cops came for me. And I used to *sit down* in the daily scrums, that didn't go down well either. All trivialities IMHO, but were made into mountains. – gbjbaanb Aug 16 '11 at 10:54
  • 2
    Don't you think in your case it is a bad, top-down implementation of Scrum that caused a loss of productivity ? You say you got "bogged down in process and bureaucracy" which is strange because Scrum is the simplest least bureacratic methodology in the world... Actually the whole Scrum framework fits in one sheet or 2. Btw what you call the "scrum board" is not part of the framework. In Saeed's case though I do believe the problem is a gap between the type of organization he worked in (with great freedom and power of decision to the developers) and the type of organization Scrum applies to. – guillaume31 Aug 16 '11 at 15:16
  • 3
    @ian31: yes, that project was particularly bad, but Scrum appeals itself to those kinds of managers. You never see them choose Kanban or Crystal after all. Scrum too easily turns to "scrum but" when these guys get hold of it. pity. – gbjbaanb Aug 16 '11 at 16:19
  • 1
    I think it's hilarious that any company would turn Scrum into a religious ceremony. Hey! Stand during this ceremony where we pretend to be agile! Hey! Smile while we pretend to listen to you, and then merrily continue doing what we wanted to do anyways! – Warren P Oct 17 '13 at 01:56
  • 2
    I totally disagree with the thrust of this answer. I think some kind of "mini-waterfall" can be very beneficial, especially for inexperienced but clever developers, who are liable to do 5 different things at once and not finish any of them. In fact the person who trained me in Scrum said that you can still do "mini-waterfalls" in Scrum if you want, but ideally, they should be over a period of days or even _hours_. I thought, hours is too short. You can't always design->implement->test a story in a few hours. And splitting stories so that you can is not always optimal either. – Robin Green Jan 05 '14 at 12:19
11

I'm guessing before Scrum, everybody just did what the wanted: yippee ki-yay mf'er. Your users are your benefactors and they drive the story and pay the bills. The product owner makes sure the story gets done. Some how, your group came to the conclusion that the Product Owner should be telling you how to program.

You want to write code or make neat little apps that you think are cool? "I want to do feature A first and not B, so I can maintain my freedom of choice." Find a different benefactor and not a new develoment methodology.

You're caught up in the Project Owner title or something. If you have a valid reason to disagree with the story, say something, make your arguement. You may not always win. It's their job to return to the users and let them know there is a valid issue with their request. Let's face it, if the story asks you to drop a database randomly throughout the day, without a backup, no loss of data or down time, you have a problem and a duty to set the story straight.

JeffO
  • 36,816
  • 2
  • 57
  • 124
8

I think, that simply you guys are used to having more ownership - and everyone I think prefers that, its human nature.

Unfortunately I think a lot of software is less than it could be, because often parts are written for the dev and not the client. Your new approach should reduce that, but at the expense of your ownership feeling.

I've no idea how to suggest you make things better or more fun but it's a great question and a very good insight.

Jonno
  • 1,738
  • 10
  • 17
  • 100% agree. You are now more aligned with the product owner but that in term that means you have less freedom to do what you think is right. I've experienced this too and it sucked and made my job a lot less enjoyable. But it meant that I was much better aligned with the business and the product manager goals. The business pays the bills - including my salary - so yeah, they get to say what they want at a detail level. I don't think they're actually telling you how to code. If they knew how they could do it themselves. – Michael Durrant Jul 19 '13 at 01:46
  • The business doesn't pay developers to do what they want. They pay developers for the productivity gain a good software environment provides. If you let the business tell you what to do "at a detail level", do you really think they'll get the good software environment they are looking for? – Andomar Nov 25 '13 at 14:56
  • @Andomar - It's a balance. Each side has it's ideals, assumptions and faults. Ignoring any of these leads to peril. – Jonno Nov 25 '13 at 22:38
5

Are you getting user stories in the form of "As a --role--, I want --goal/desire-- so that --benefit--"? It sounds like your Product Owner wants to do the design work, and he/she may not be the best person to do that. Using the user story pattern can help ensure that the Product Owner is sticking to the business interest, and the software development is being done by the software developers.

Michael Munsey
  • 119
  • 2
  • 4
    As a developer I want never to see this kind of user story again, so that I may never have to groan inwardly at its inanity. – Warren P Oct 17 '13 at 01:57
  • @WarrenP Yes, boilerplate can be a pain, whether it comes in the form of boilerplate code or boilerplate requirements. I think the key point is that all of those 3 elements should be either stated or understood, but more importantly, it should be clear to everyone what is really wanted, and boilerplate templated requirements can actually hinder that. Especially if developers start to think that filling in a few short words into that template is always sufficient. – Robin Green Jan 05 '14 at 12:24
4

In Scrum there is plenty of space for the developers to contribute and give their advice on new features, UI, usability... Collaboration and conversation between business people and developers is required in Scrum and it allows that. However in the end the product owner will always have the final say because he's the one responsible for maximizing the business value of the software increments produced sprint after sprint (in other words, the ROI).

From the Agile Manifesto :

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The product owner telling you how UI and functionality must be implemented isn't acceptable though. In that case you should have the final say since you are responsible for the internal quality of the software you produce.

Maybe you work in a company created by developers where programmers had freedom to implement whichever features they wanted. However, most Agile methodologies make a clear separation between business domain people and the team responsible for producing software (developers, testers...) which is the most common work division in most places. If my assumptions are right, I can understand the feeling you have that you're not able to "have an influence on the big picture" anymore but with the company growing I guess that would have been the case anyway, Scrum or not.

Regarding analysis, design and other meta-development activities you mention (which again are not supposed to be done by the Product Owner), Agile teams are supposed to be cross-functional and silo-free. No one is supposed to possess all the knowledge around one specific development activity, so maybe there's an opportunity for you to diversify there vs just "code monkeying".

guillaume31
  • 8,358
  • 22
  • 33
3

On the contrary, I've found that having a product owner make decisions about functionality allows me to devote more time to producing quality code. Plus, if there are valid concerns, I can always question the product owners' decisions, and that usually leads to fruitful discussions.

Misko
  • 1,070
  • 6
  • 6
3

We practise Scrum here. We have a fortnightly planning meeting where we feed in the current business priorities, and successes and failures from the previous sprint, and we decide, as a team, what we want to tackle for the next sprint.

One of the ways we do this is to sort the backlog on a board by complexity vertically, and business priority horizontally. After that, the Product Owner has had his input, so it's up to the team to pick off what we want to do. Obviously, picking off a high-complexity low-priority task is frowned upon, but we are deciding this as a team. It makes planning sessions longer, but it's worth it, and a core part of the Agile process.

And we do have micro-management sometimes, but that's a different problem.

Tim
  • 1,427
  • 10
  • 11
3

The real problem you're describing is a common pathology when teams adopt a Methodology: they turn off their brains. This is as true with a new-school agile system as it was with old-school heavyweight systems.

Q: The Methodology prescribes x, but x isn't working well. What should we do?

A: Refine your implementation of x. Maybe stop doing it altogether. The Methodology isn't the boss of you!

In this specific case, it sounds like the product owner might be doing too much. Are you comfortable talking to him about that? Would you be comfortable having that conversation if you weren't "doing scrum?" If the product owner isn't sensitive to constructive feedback, it's not a methodology problem, it's a problem with the product owner.

Ian Olsen
  • 21
  • 3
2

I'm not really in tune with the whole scrum thing as have been more waterfall for a while.

But to be honest, this sounds more like a management personnel issue than a project management technique issue. As in it's more people based than technique based.

temptar
  • 2,756
  • 2
  • 23
  • 21
  • No @temptar, our relationship is really good. No offense, no hatred, nothing at all. Everything is fine, everything except how we feel towards the work. – Saeed Neamati Aug 16 '11 at 10:01
2

I had the same experience with Scrum and like to call it the "tyranny of the story".

From my experience developers more on the creative/design/frontend side seem to suffer more from it than people involved in backend work.

The only way out I found so far was to either ditch Scrum – often not possible and/or appropriate because after all it has it's advantages – or to introduce something like Google's 20% time to give developers a creative outlet apart from the "you're free to choose how to implement the Login Page", because in reality you are not as your implementation is constrained by the existing code and system architecture – that is unless one considers the freedom to choose between 'a for and a while loop' a freedom.

Alexander Battisti
  • 1,622
  • 11
  • 11
2

The Role of Leaders on a Self-Organizing Team would be a blog post about something that seems to be missing from your post. Where is the team deciding what work gets done in a sprint? Where is the team having ownership in the process and the work? Do you have someone that knows Scrum enough that you are doing Scrum and not some perverted version of it?

Glorfindel
  • 3,137
  • 6
  • 25
  • 33
JB King
  • 16,795
  • 1
  • 40
  • 76
2

As per my experience, Scrum is to deeply watch you what you do. It is just sitting on your shoulder and watching what you do. Even though it has its own advantage, I hate the scrum methodology. It expects the count, not the quality. Quality is getting compromised with scrum methodology.

Anto
  • 1
  • 1
  • "Quality is getting compromised with scrum methodology.": Maybe it is a bit extreme to say that quality gets compromised but, yes, controllability of the project gets a higher priority than quality. – Giorgio Jun 27 '14 at 05:04
  • Amazing how little some people know about scrum or agile, and yet how they post like authorities. One gets the impression that an individual worked for a few weeks on a dysfunctional group where they said they were "doing scrum" and concluded that is how scrum is supposed to be. In this case, it's a completely anonymous guy with only one post or comment in 4 years, and no evidence of expertise on the subject. This is why we can't take many of these comments very seriously . – Curtis Reed Feb 20 '18 at 19:22
1

There is a big difference between you deciding what to do, or being told what to do.

In my experience, there's just a rather long way from being told what to do to deciding what to do.

At the end of this way it usually turns out that we were instructed not because them like power and not because them have nothing better to do. Quite the opposite, at the end of this way - when they gain sufficient confidence in our team - they seem to be relieved and happily pass us as much control as we can handle (and if their trust is really firm, they even try to pass more than that)

Oh and in my experience this has basically nothing to do with Scrum/agile. Happened with scrum, iterative, waterfall, whatever. Seems the matter of trust is er process agnostic

gnat
  • 21,442
  • 29
  • 112
  • 288
1

In our team, the product owner tells us what to do and we decide how we do it. It is really important to have this separation or you'll end up in the situation you have described.

thegreendroid
  • 359
  • 2
  • 13