Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

We're looking for long answers that provide some explanation and context. Don't just give a one-line answer; explain why your answer is right, ideally with citations. Answers that don't include explanations may be removed.

4  
Are you sure you weren't just committing yourself dysfunctionally much before? –  Donal Fellows Aug 16 '11 at 10:28
21  
Nice blog post. –  Robert S. Aug 16 '11 at 13:25
17  
what you are describing isn't SCRUM –  Jarrod Roberson Aug 16 '11 at 13:36
2  
@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 4:55
3  
@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. –  Chad Aug 17 '11 at 13:03
show 5 more comments

17 Answers

up vote 46 down vote accepted

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 butt"? 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.

share|improve this answer
9  
+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
1  
@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 at 8:16
show 2 more comments

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.

share|improve this answer
29  
Amen to that last line –  Wivani Aug 16 '11 at 14:33
5  
"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 7:56
2  
"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 3 at 21:16
show 1 more comment

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.

share|improve this answer
1  
Human nature will always find a way to snatch defeat from the jaws of victory. –  Warren P Oct 17 '13 at 1:54
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 3 more comments

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).

share|improve this answer
6  
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 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 Jan 5 at 12:19
show 1 more comment

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.

share|improve this answer
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 1:57
show 1 more comment

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".

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
show 1 more comment

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?

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
show 1 more comment

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.

share|improve this answer
add comment

protected by gnat Jun 27 at 7:27

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

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