42

Conversation is Not Inherently Disruptive I work with a team of developers who are talented but often distract each other with chit-chat. You say they are "talented but distracted." What makes you think they are talented? Why do you think they are distracted? What is your metric for determining that the team or the process is operating at a sub-optimal ...


39

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


20

It is possible that a developer also acts as a product owner but I don't think that it is recommended. Here are my 2 main reasons: It may create conflict of interest It will drag down your output as a developer PO has to prioritize the backlog (the what part) where as the team decides amount of work that can be delivered in each sprint (the how-much part). ...


11

TL; DR For the immediate future, you need to spend more time working with the Product Owner and less time focusing on the development team. You and the Product Owner both need to spend a couple of sprints refining your roles and learning to work together, and you both need to gain a better understanding of your respective roles in the Scrum process. Fix ...


10

I don't know why aclear16 deleted his answer. His answer is perfect. There are a ton of positives with idle, unproductive time by way of teaming. It matures the team and you want that. I'd even go as far to say that, if you are running behind, let the social time continue because the positive aspects of that will help, not hurt. And likely the down time was ...


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

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

The first issue you must face: Are distractions good or bad? I think this can not be answered with either a clear yes or no. First, no developer can work 8h on end and still remain sane. On a good day you get 4-6h of concentrated work. But don't think that, since they are not sitting concentrated at their desk that they are "not doing work". In my ...


8

Kanban: Not a Day Planner The Kanban framework is not a day planner. You are not supposed to add all your routine chores and obligations to the Kanban board. Kanban is a pull-queue system, and columns on the board ought to represent process queues. Cards May Contain Task Details An individual kanban (the card itself) may contain additional details such as ...


8

1) Accept the fact that the PO needs help and that the developers are the most qualified people to help. The product owner and the developers together form a team. Nobody's time is more or less important than another. They work together to develop software. The team can't be expected to use their valuable time effectively if they don't have good stories, so ...


8

While the Scrum Guide does not explicitly state whether the Scrum Master or Product Owner are, or are not part of the development team, they are part of the Scrum Team: The Scrum Team consists of a Product Owner, a Scrum Master, and the development team. Which infers that both the Product Owner and the Scrum Master operate outside of the development team....


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

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


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

Conceptually, it's pretty simple. As Project Manager, you are responsible for the success of the project. It gets complicated by technology and people. Upfront: Make sure you have clearly defined goals for the project. There should be very clear requirements about what the final product should do. Make sure the people assigned to the project clearly ...


7

I second @sqreept opinion (+1!), you're trying to deal with the symptom rather than with the cause. Having said that, my opinion below only represents a few between all possible scenarios. Now, the scenario: my team is chit-chatting a little bit too much Why? Because they know they have loose deadlines to meet. Why? Because developers tend to be ...


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

In order to have a valuable research one usually needs to define it's purpose and goal. So, in other words, developer knows what he wants to do, what is his progress and what are the problems he is facing currently. The question is, how to share such knowledge in a meaningful way. If the meeting involves only a status report then there is only a concern ...


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


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