178

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


23

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


17

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


14

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


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

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


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

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.


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


11

There are a couple of key points to get out of the way: Agile != lazy development Spikes and Prototypes are not interchangable ideas Nothing that you described above is prescribed by agile or scrum To your question about how to make your case, it depends on their real motivation. If they don't understand the impacts of what they are doing, you can make a ...


10

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

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

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


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

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

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


6

The key point of Velocity and user story estimation is to serve as relative measurement of what can developers finish during sprint. Velocity should not be used to compare to other teams. So, if the developers will over-estimate the user stories, the velocity will go up and they will be forced to either do more work next sprint or over-estimate again. This ...


6

Apple has this scenario covered. Your client will need to join the iOS dev program so they can post things to the store. They can then add you to their program for development certificates and such if you don't have your own as well as provision an iTunes connect account for you to publish to the store on their behalf. I would advise getting your own iOS ...


6

For a startup, what are the pros and cons of building a software product predicated on "Throw away code" vs "an extendible codebase"? In reality, if you phrase the question as "either one or the other", it might reduce your options significantly. I feel like you kind of answered already the pros and cons in the question, so I'll try to exercise the real ...


6

If you're talking about a single product/project and a single pool of developers, I would strongly recommend having just one product backlog with all the items you mentioned included in it. Having two backlogs will be an admin nightmare, and I'd imagine that you and the product owner will be fighting for resources to work on your respective backlogs. If ...


6

I would say no. Considering that the PO should focus on defining business value. Having the PO creating prototypes kind of influences the teams development in technical terms. I think it is important that the business value is well defined, so that the team can implement it. Also, the act of creating a prototype is a learning experience, to figure out how to ...


5

With your talk of developers and product owners, it seems to me that you have no middle person responsible for the features in your organisation. Well, in my organisation, I am that person. I am the requirements engineer, the one who learned how to make good specifications and choose features which result in a high quality software with user friendly ...


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