40

Tom is an unguided projectile. Regardless of why he does what he does (whether he believes himself to be better or simply lacks proper guidance), the core issue here is that he not only second-guesses any information/objectives that you give him, but he will independently decide to follow his own instinct. if the wireframe puts a blue color button, he ...


21

Flater's answer is really good; let me add something that will also help: Acceptance Criteria (AC). Acceptance Criteria Every single story should have Acceptance Criteria, describing the functional effects of the story with a binary (true/false) answer. If a story is incorrect or lacking details, then this is the fault of the team during grooming/planning. ...


10

The Scrum Guide is explicit that this is allowed: The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.


10

First, stop measuring individual velocity. Velocity should be measured on a team level for a Sprint, and not for individuals. Your team delivers a potentially shippable software product after even Sprint, not individuals. Since Scrum is built around self-organizing, cross-functional teams, your velocity should include everything involved in creating the ...


9

TL;DR You already know you shouldn't do this. However, if you must do it, focus on team integration and support of team values, rather than trying to perpetuate the 100% utilization fallacy or applying irrelevant metrics like lines of code written or bugs stomped per iteration. If the person makes the team better or the process more effective, then they ...


9

First off, I should note that, as per my understanding of the term 'cross-functional team', it is not a team where every member can do everything. Rather, it is a team that is capable of doing everything. If your team is capable of taking a project from start to finish without waiting on dependencies, then it is cross-functional. If the team has to spend a ...


8

Let's tackle your questions from the last to the first: 3) Is there a reason why it seems like there isn't a lot of attention dedicated to this topic specifically? Yes, there is. The whole thing of project-management processes is about solving problems like inner-team communication, work sharing, team conflicts, responsibilities, ... the complexity of ...


8

Disclaimer: I have never worked in a digital agency and I am aware that the role of Project Manager in Digital Agencies can be somewhat different to that commonly accepted in other I.T. operations whether in-house or software development suppliers. Furthermore I am not clear on the exact differences. Despite my disclaimer above, and taking the question and ...


8

Reflect the pain back. As things stand, your boss is not feeling the pain the team is feeling in delivering against artificial and aggressive deadlines. Your challenge is to make sure they see the consequences of their actions. Produce a sprint report that details what has or has not been tested. Make it clear that by accepting a release under these ...


8

It's important to recognize that Scrum does not say that a team must be between 3 and 9 individuals. The Scrum Guide says that Scrum is most effective with a Development Team size of between 3 and 9 people. A Scrum Team (including the Product Owner and Scrum Master) would have an ideal size of 4-11. Development Teams that are smaller than 3 people or larger ...


8

This is a problem most of the PMs face when there are really skilled Developers in their teams. My answer will be a practical approach to handling this issue. I hope you have been a PM for quite some time and have experience and have established yourself as a PM in the organization. Basically, you have a say in the organization. Since Tom is an ...


7

TL;DR If you're still thinking in terms of strongly-defined roles rather than cross-functional teams, then you're not making a successful transition to an agile process. Agile teams may need all of the skills you've listed, but each of those roles is actually the responsibility of the whole team rather than of individuals, and it is up to the team to ...


7

If you really mean SPOCK then you are probably referring to the testing and specification framework for Java and Groovy applications by SpockFramework.org Spock is a testing and specification framework for Java and Groovy applications. What makes it stand out from the crowd is its beautiful and highly expressive specification language. Thanks to its JUnit ...


7

I work as a developer and can so clearly see myself in the shoes of Tom; I guess he reminds me of myself. I can see in your profile that you've written about Tom in July as well, so I realize that this is great concern of yours. Of course I don't know the details about your situation, but I will try to elaborate my own view. It has happened to me that I ...


7

By estimating iteratively. Look into the cone of uncertainty. At the start of the project, the amount of uncertainty is high, and the cone wide. Thus, your estimate would be 'between 2 and 6 months'. Partway through, the uncertainty lessens and the cone thins. One month in, the cone becomes '3 to 4 months'. 3 months (12 weeks) in, it becomes '13-14 weeks'....


6

Basically, you can lose real money you can put your family in jeopardy (loans, mortgages) there won't be anybody who'll help you out (like parents, teachers) if you are in trouble you'll be responsible for the life of others (your employees) nobody will give you an idea (like teachers do), you have to find them there won't be such thing as end of semester ...


6

Here are some pitfalls I've seen with the MoSCoW model. Managers are worried that their requirements will fall into "should" or "could", and won't get done, so they make up reasons why their requirement is a "must". This ends up delaying business-critical functionality. (This is usually caused by, or exacerbated by, bad KPIs at an organizational level. I'm ...


6

The ratio depends on the company and how software and project management oriented the management team is. In my experience, the majority of staff in an agile software team were testers, because the corporation focused on user experience and prior to delivering the final product to the customer, they needed to ensure that the product was "bug free" and that ...


6

You are solving wrong problem Your PM is completely out of control and #1 task is to get Projects back to PMs hands. They're now run by the Client and Developers, which is not really their job. . There are many dangerous signs in case description: "senior developer promised would be delivered over a month ago". What does "developer promised" mean? Isn't ...


6

Nothing in Project Management is Free It is usually very difficult to explain to management that it will take time to repay technical debt and that the team will be even slower refactoring rather than delivering features. You already know the answer: you can't create a bigger pie by carving it into more slices. Ultimately, a team has a finite amount of ...


6

Agile provides 3 opportunities to catch this error prior to production The dependency should have been captured in the acceptance criteria: When story B is written, it should have been linked back to story A. And an acceptance criteria should have been written to capture that. Unit test should break: While not all Agile teams may be writing unit tests, ...


6

Have you considered paired programming? In areas completely foreign to them, the other developer could be the "driver", allowing them to get some good insight into this project. It'll also keep them from spinning their wheels a long periods of time when taking on challenging pieces of code (to your point about deadlines). Interestingly, I've found it also ...


6

Leaders of teams are not only because they were officially designated as said leader of a team. They lead because they assume the role and once assumed they are the de facto project manager and are responsible and accountable for the project in the exact same way as if they were officially designated. You cannot lead the team, be looked at as the leader of ...


6

EI and conflict management goes hand in hand. EI will be useful in all areas - Negotiations with client during inconvenient situations Motivation to resources who may not be happy with their role/responsibilities or senior management Conflict between team members Your team member may not be happy with you as well, you dont have to take it personally and ...


6

Optimize for Flow, Not Utilization In Scrum, when picking a set of stories to accomplish in one sprint, some sprints will have mostly art-heavy stories queued up, and some sprints will have mostly engineering-heavy stories queued up. By picking the next most important stories, we'd be committing to having some disciplines sat idle once their part is done, ...


6

That project needs to be released in 2 months, but we estimated around 6 months of work on it. So we need to get more people working, so that we can fit in that time period. Adding more developers will not solve your problems. Study of The Mythical Man-Month by Fred Brooks is recommended. Also Testing & Verification should happen alongside of the ...


6

Fascinating question and an excellent interview question. (Technically a poor fit for PM:SE because there is no authoritative answer - which is what makes it a great interview question). That said, I think it is fascinating. I think you covered the most important element - which is to avoid acting as a developer. So what does the manager do that the ...


6

This is a behavioral problem and not specific issue which can be addressed by any framework or development methodology. As a leader with specific goals to be achieved in defined timelines you need to develop strategies which helps you achieve the goals. You might be doing many of the standard suggested practices as well, but it will be helpful if you can ...


5

TL;DR In our current project we have pushed documenting it (other than deep technical detail) out to the end of our sprints. Is this a sensible plan? Nope. Technical Writing for Agile Teams The Agile Maifesto values: Working software over comprehensive documentation...[T]here is value in the items on the right, [but] we value the items on the left ...


5

Some answers are refering to the Scrum Guide when they say no. However, according to that reference I'd say it would be no problem for both the SM and the PO to develop, given the right circumstances: The Product Owner and Scrum Master roles are not included in this count [the development team size] unless they are also executing the work of the ...


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