182

Good answers so far, but they don't cover all the bases. In my experience, many people fresh out of college have fantastic theoretical knowledge - far better than me or many other seniors with decades building software for a living. BUT, and that's a big BUT, that knowledge isn't grounded in any practical scenario. In the real world, a lot of that theory ...


47

The reason a lot of developers are "passive," as you put it, is because it takes a certain amount of domain knowledge and experience before good product ideas come to you. But if they do come, there's no reason not to suggest them and champion them. Keep in mind - developers, product owners, sales people, etc., are all on the same team, with the same goal: ...


43

Yes but with a lot of care! Let me clarify that. You should strive to improve the habitability of the software. If you look at the code/team/business/project/management and your first response is to take a shower, then it is not habitable. If your first response is to shout yeah!... and then complain when you are turfed out of the office, then you need to ...


27

Don't listen to anyone who says "your own time is your own time, just don't tell anyone!" because that's incredibly bad advice that is almost certain to land you in trouble, if not at your current job then at some future one. Not only do employment contracts vary too widely and significantly for any kind of generic advice to be useful, but different ...


22

It is always a good idea (especially in so-called Agile projects) not to stick to some cargo cult or text book telling you "who should (not) talk to whom", but switch on your brain and do whatever works best in a project. Though the communication between PO and the customer should be the standard (because of the reasons scetched by @PatrickHughes in his ...


20

Yes You can. BUT... You have to be careful. At the begining of my career (very long time ago) I was lucky/unlucky to get into a few months old project as the "Junior". As the first thing I noticed, there was (OMG) no code repository! All merges of code were done manually by sending zip files to each other by mail. So I went to my (also new) manager and ...


16

It depends on how easy it will be to convince the powers that be to throw away the live prototype. You see as soon as prototype / proof of concept, goes live, it becomes a real live system. And the "powers that be" will want you to make modifications and changes, and whilst this happens it will gain real world use, and then it is not so easy to replace. ...


15

Without a contract in place, most common law says that the program and copyright to the code belong to your friend. Essentially, he employed you for a task and paid for your labor so you were his employee*. And that implies that you aren't allowed to sell a copy to a second friend since you don't own that application. Your first friend owns it. However, ...


14

I think the answer is you both should be thinking about your own set of edge cases. He as the dev should handle edge cases that are data specific such as does the app crash from any given user input, 5 / 0 certainly falls into this part of the spectrum. The dev should ask about you what you think would be an appropriate error message when the input given as ...


14

Is it worth a (junior) developer's effort to try and push for the above as time goes on? Yes, it is always worth your effort to try and make things better. You know best what problems you face after all. But as you mention, there are lots of problems to solve and many of those problems are not terribly valuable. And at a lot of places, there will be ...


13

Embrace this... you see, Agile does NOT mean the proscribed ways of working are what you have to do. It means you get to decide what works for you and do exactly that. Now I'm sure, given that advice, your team will become effective immediately with the Cobol guys doing their thing and communicating with the .NET guy who'll do his thing. Hopefully they'll ...


13

The usual approach is that anyone can add stories to the backlog. The product owner prioritizes them and the team estimates them. Story quality issues generally get taken care of one way or another in planning meetings or retrospectives. That means the product owner isn't a bottleneck as long as you're satisfied with the priorities he's assigning. ...


12

This is what the backlog is for. New requests get put on the backlog, and priorities can only change on iteration boundaries. An average of one week delay (half of a two-week sprint) is plenty agile enough to handle all but the most dire emergencies.


12

You're very close in your title. I believe the term you're looking for is Quirk Parity by Kent Beck: "quirk parity" -- the part of a rewrite where you finally match the irrational behavior of the old system This arises from the Common Law Feature


12

Yes. But organizational change is hard even for a senior so if you really want to make a difference do it in the right way: Not during the first weeks: Use this time to: Create a good first impresion. Show that you fit in the team. Understantand the culture and politics or your company. Is it safe to push for changes? Build a good relationship with ...


11

I would recommend, whenever possible, having the Product Owner be a representative of the customer. The role of the PO is to be the voice of the customer, to ensure that what the team is producing adds business value, and write and prioritize user stories. Who better to perform these roles than a willing participant from the customer's organization? The key ...


11

In Scrum there is no TL as official role, so let me first answer the question from a Scrum perspective. Everyone in the team can "challenge" a PO in order to get more information, but it is the PO who is responsible for deciding "what" needs to be done. It's important that the team trusts the PO's decisions about "what" needs to be done, and the PO trusts ...


11

The team needs to work together as opposed to having a "Not my job, not my responsibility" type of attitude/mantra. Acceptance criteria comes in the form of: Business Acceptance Quality Assurance Acceptance Typically the business acceptance is usually answering the question: Does the feature that has been implemented do what I want it to do? The feature ...


9

In general, the role of the PO during a sprint should be passive, i.e. provide feedback when asked for it, but not micromanage the work of the team. Any changes that result from such feedback have to be weighed against other priorities. But ultimately, the PO represents those paying for the project and thus calls the shots. As for your specific questions: ...


9

Here is how I dealt with a similar problem .. Back in the days when we were agile before Agile. For any change request, the customer sets the priority. The developer can only, and must, stop work on a task to work on a higher priority task. Equal priority tasks are schedules in order of arrival. (Task Priority cannot be changed once work has started.) It ...


9

Ask for feedback from the developers which were part of the team developing the product he 'owned'. You could ask questions like: Was he able to answer requirements related questions in a timely manner? When presented with multiple alternatives in regards to a feature, was he able to make a clear decision with regard of what he wants? How often did he ...


9

Yes. But not the things you suggest. Out of your list Unit/Integration tests are the only item you can make progress on. You can start adding these by yourself with minimal time investment and show instant value. Its a technical problem with widely accepted benefits and wont affect others work practices. While also gaining you mdore knowledge of the code ...


8

The line manager simultaneously embraces Scrum and has a hard time "letting go"; he has the Product Backlog in his head and also prioritizes it. I'm assuming that your line manager is filling the role of Scrum Master. In this example, he's not embracing traditional Scrum roles. One of the key aspects of any agile methodology is high visibility. That means ...


8

To me, it doesn't seem that the role of a product owner goes against the idea of open source. The ideas of open source software is that of freedom to learn, improve, change, and distribute in the best possible manners that solve real-world problems. It's all about collaboration to create a product that's available to the general public and that's usable, ...


8

The Product Owner does not have an active role in the daily stand-up meeting in Scrum. He/she can listen in to get a sense for what is going on in the team and how they are doing on their commitment. The Product Owner should remain in the background during these meetings and not speak up. If the Product Owner has grave concerns, the he/she should take that ...


7

The concept for Benevolent Dictator for Life is similar. Certain Open Source projects have creators that aren't necessarily directly involved in every change but have either an explicit or implicit veto on anything that happens with that software or language. Examples include Larry Wall of Perl, Guido Van Roussom of Python and Linus Torvalds for Linux.


7

From the Jargon File: bug-compatible /adj./ Said of a design or revision that has been badly compromised by a requirement to be compatible with fossils or misfeatures in other programs or (esp.) previous releases of itself. "MS-DOS 2.0 used \ as a path separator to be bug-compatible with some cretin's choice of / as an option character in 1.0."


7

Generally speaking, the person who knows the most about the application requirements or has the responsibility for interfacing with the client is the one who should be the Product Owner. If the development managers in your organization have the best knowledge of the product's requirements, then they ought to by the Product Owner. Developers need to be able ...


7

I don't see why you shouldn't. Especially if your organisation is large enough to support up to 30 developers dedicated providing development support infrastructure and tools - I'm hoping that you probably have at least 10x that many other developers consuming these tools. The role of the product owner for an internal product is no different than for an ...


Only top voted, non community-wiki answers of a minimum length are eligible