106

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?

Improve this question
15
  • 4
    Are you sure you weren't just committing yourself dysfunctionally much before?
    – Donal Fellows
    Commented Aug 16, 2011 at 10:28
  • 27
    Nice blog post.
    – Robert S.
    Commented Aug 16, 2011 at 13:25
  • 20
    what you are describing isn't SCRUM
    – user7519
    Commented Aug 16, 2011 at 13:36
  • 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
    Commented Aug 17, 2011 at 4: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
    Commented Aug 17, 2011 at 13:03

17 Answers 17

Reset to default
49

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.

Improve this answer
4
  • 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
    Commented Aug 16, 2011 at 12:17
  • 7
    "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
    Commented Jun 27, 2014 at 4: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
    Commented Jun 27, 2014 at 8: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
    Commented Nov 7, 2014 at 2:32
64

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.

Improve this answer
5
  • 39
    Amen to that last line
    – Wivani
    Commented Aug 16, 2011 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
    Commented Aug 16, 2011 at 19:11
  • 1
    +1 @Lukas, because of the differentiation between what and how. Thanks buddy.
    – Saeed Neamati
    Commented Aug 17, 2011 at 7: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
    Commented May 3, 2014 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
    Commented Jun 27, 2014 at 12:31
27

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.

Improve this answer
2
  • 3
    Human nature will always find a way to snatch defeat from the jaws of victory.
    – Warren P
    Commented Oct 17, 2013 at 1: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
    Commented Apr 7, 2015 at 0: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).

Improve this answer
6
  • 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
    Commented Aug 16, 2011 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
    Commented Aug 16, 2011 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
    Commented Aug 16, 2011 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
    Commented Oct 17, 2013 at 1: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
    Commented Jan 5, 2014 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.

Improve this answer
9

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.

Improve this answer
3
  • 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
    Commented Jul 19, 2013 at 1: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
    Commented Nov 25, 2013 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
    Commented Nov 25, 2013 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.

Improve this answer
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
    Commented Oct 17, 2013 at 1: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
    Commented Jan 5, 2014 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".

Improve this answer
4

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.

Improve this answer
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.

Improve this answer
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.

Improve this answer
3

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.

Improve this answer
2
  • "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
    Commented Jun 27, 2014 at 5: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
    Commented Feb 20, 2018 at 19:22
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.

Improve this answer
1
  • 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
    Commented Aug 16, 2011 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.

Improve this answer
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?

Improve this answer
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

Improve this answer
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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.