Hot answers tagged

14

All work is probabilistic. It has an extremely improbable best case result, an extremely improbable worst case result, and an extremely probable most likely result. That probabilistic distribution is driven by both random and non-random variables and a PM, no matter how talented, can do absolutely nothing about the random variables and can likely affect ...


12

checking SVN in a daily basis to review codes and to assess how much codes have been committed by each developer is a good way. is it fair and used in industry? The proposed metric is utterly unfair, regrettably is used in some organisations and is in my personal opinion a recipe for disaster. HasaniK and Jakub have already identified some very valid ...


10

checking SVN in a daily basis to review codes and to asses how much codes have been committed by each developer is a good way. is it fair and used in industry ? This is definitely not a correct measurement for a PAR for Software Engineers. As Jakub has also mentioned, design takes time,sometimes there are blockers which prevent dev team from finishing a ...


8

Yes, a project manager is responsible for completing a project on time. However, "on time" is a date that will often move during the life of the project, and it is the agreed date that the PM should be measured against - not necessarily the original date. The initial date may be agreed by all concerned, however requirements may change, issues are ...


8

I would ask myself a fundamental question: If I don't have stakeholders, who am I building this product for? In your situation, it sounds like you're building it because the owner of the business, your product owner, said so. No problem. In other words, your product owner isn't representing stakeholders, he is your stakeholder. Cool! But there's a catch. ...


8

A couple of suggestions: Code Quality Tools It is worth thinking about using automated code quality tools like Findbugs, PMD and Checkstyle. Ideally get the team to agree on a set of coding standards and implement them as templates in the various code quality tools. Then run the tools from continuous integration and possibly even fail builds when the ...


6

TL;DR Scrum is a collaborative process between the three defined roles (Product Owner, Scrum Master, and Development Team). You are experiencing problems with your Scrum implementation because your Product Owner is not collaborating throughout the process. The Scrum Team (including the Product Owner) collectively agree to a Sprint Goal for each Sprint, as ...


6

Let the Team Self-Manage Its Processes and Supporting Tools Scrum doesn't mandate code-level practices. From a framework perspective, that's an implementation detail that's up to the Scrum Team to decide. Ideally, you shouldn't be "assigning" anything to anyone. Scrum (and agile practices in general) are based on pull queues and collaboration. The central ...


6

A project manager has the overall responsibility for the project's success. But what is project success, you may ask? Many executives see project success as delivering software on time, on budget and packed with features, which history has shown, time and time again, that for most projects it's impossible to do. Even if you have the right kind of people and ...


6

What's your interpretation of a ScrumMaster? I am asking because doing an employee evaluation is not a classical task of a ScrumMaster. Regardless if the evaluation is somehow related to the agile process or not. But we do not have a formal feedback process from the Scrum team to managers for individual team member. I am not sure if this would be a ...


5

I agree with the other two answers, but I'd phrase it slightly differently. The Project Manager's primary responsibility is to manage the expectations about the project's completion date. This can involve Working with the project team to ensure that work is accomplished to bring the project to completion at/under/near the estimated completion date. ...


4

I differ from the opinion of @CodeGnome. Processes and plans cannot be one-sided - they need to be agreed on by all parties to the project or any system. In your case, the client is clearly not in agreement with you - for reasons that you have not spelt our or perhaps you are unaware of. Neither is your senior management willing to work with you to solve ...


4

It would be worth taking a step back and thinking about avoiding the problem in the first place. The sprint review should not be the first time the Product Owner sees the functionality built during the sprint. They should be exposed to the functionality at the earliest opportunity, this is often when it is still under development. Typically the sprint ...


4

So right now, as an Engineer, I take a single task, mull over it for 4 weeks, make sure it contains no bugs at all and I am the best worker you ever had. Despite the fact that it took me 4 weeks to deliver such a simple task. On the other hand, you have QA, who is wildly dependent on getting a crappy Engineer assigned. The crappier the engineer, the more ...


4

I can only speak for software projects. The team as a whole ought to be responsible for success and timely delivery. If you are dependent on a PM to get the project done on time then you surely have a dysfunctional or disengaged team. If you wanted to single out one person having a greater part of the accountability for success then it should be the Product ...


3

Are the goals that the review can be audited? or to prove the auditor is doing his/her job? We document them as new tasks/discoveries on our Scrum-board and some just picks them up. I think the main goal of code reviews is knowledge sharing and finding recurring code mistakes, not the documentation, unless you need it by law :) Checklist based code reviews: ...


3

My answer is: you should not to monitor review comments at all. Try to trust to your team. It's help to avoid micromanagement (like monitoring review comments). If you are Project Manager, you should think about business. If you are Functional Manager, you should think about development process. But only developers (including tech lead and architect) should ...


3

If you want to monitor the effectiveness of the comments, have you considered putting in a code review - review system? So the person being reviewed could rate the helpfulness of the feedback from 1-5 or something. This way, you could measure the effectiveness of the code reviews people are giving without having to make the determination on your own. The ...


2

Ideally the review meeting should include the product owner and the client to share their feedback with the team. Whether you're working on an internal product or a client based project, it's recommended to invite both of them and have the team walk them through the done features and if you have time run the acceptance tests together it would be great, just ...


2

This is a very common problem. The short, direct answer is that the Sprint Review should not be the first time that the PO sees the completed stories. The PO should review stories as soon as they are done in the sprint. This will free up the Sprint Review to focus on feedback. There are three other points in your question that are worth addressing. 1) If ...


2

It seems rather nitpicky to determine if the order of reading code and performing any manual testing, especially since it's an iterative process. Since it's not stated, there's an assumption that the developer who did the work didn't just write code and throw it over the wall. They tested it, by some combination of writing automated test code as well as ...


2

I have seen the following things work: Scrum Master bi-weekly one-on-one coaching meetings: These might not have the mandate to really have an impact if the person does not want to change. This because the SM does not have any real power, but you could always advise management. Still this is the best start as you can find out what is really going on, maybe ...


1

Post-Hoc Testing is an Anti-Pattern You have succinctly described the use case for test-first development. In general, you want to first determine if you've built the right thing. Then you need to determine if you've built the thing right! With that said, the notion of divorcing functionality from code correctness is a false dichotomy. In order to meet a ...


1

In my experience reluctance to do demo's or lack of engagement with demo's results from a misunderstanding of what the demo is for. It is easy for developers (particularly inexperienced developers) to think that a demo is a progress meeting. This happens when the focus is showing how much work has been done and proving the 'worth' of the team. Demo's work ...


1

Is the purpose understood? The questions doesn't mention a specific framework or process (i.e. Scrum or eXtreme Programming) which have some intents for such an event. Why things are done is very important. What is the problem? You just don't like the way they are doing it (i.e. what does "better" mean and why is it important)? There is no involvement ...


1

It is not uncommon to have multiple stakeholders for a sprint. This is true even when your output is highly focused. There are generally two ways I coach teams to handle this. 1- Science Fair format: Have the team (or teams) set up in a large room with multiple stations. Stakeholders can then wander around to the stations they care about and see specific ...


1

My first response is to ask why. Why do you want to squish work for multiple different clients into a single Sprint? Do you not have enough work per-client? Consider 1-week Sprints instead. Is it a company mandate, with no valid reasoning? Consider challenging it. Or is it because the work for those multiple clients naturally lends itself to being combined ...


1

You could consider using elements of Test Driven Development. You might find the code reviews quicker, and no less thorough by having the tests created prior to the development, so that the developer can continuously analyse his or her progress until it meets the requirements of the pre-approved test. This could certainly reduce the back-and-forth nature ...


1

A few years back my team was in a major time/resources crunch. We solved this question by assigning a senior (me) to do the code reviews. I used Findbugs to narrow my search and identify obvious bugs, but didn't trust it fully because it was prone to report false positives. For example, it would frequently claim that the logger was and unused variable ...


1

In fact, there's no such concept of accepting/rejecting a Sprint in Scrum. A Sprint can, under specific circumstances, cancelled before it's over, but nobody can reject a sprint. Also a sprint is pretty much always composed by work that is done and work that is not done, and this is not up to the judgement of a single person. That's why a DoD is there: to ...


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