7

Both Developers and Executives Broke the Agile Contract It was due for a release tomorrow but, as a result of a review by management, needs reworking. This will undoubtedly add a lot of time onto the estimate for release. You have a basic process failure if the first time your management team reviewed the product was shortly before release. In particular,...


6

I think the crux of your question may actually lie in questions you posed in a comment, rather than in the question itself: Do you find it acceptable that release dates are not met? The answer is... it depends. It really depends on the situation; on the project itself. If it is a purely internal project that is a 'nice to have' or some such thing? Yes, ...


5

Is this a standard or good practice in facilitating a retro to 'censor' known issues like this? Yes and no. I feel it's wrong to censor anything, especially talking about impediments at a retrospective. On the other hand, discussing the whole issue again and again and again when nothing has changed is unproductive and wasteful. As an example: in my old ...


4

I used to work at a company where post-mortems were fun, and we looked forward to them. A clear list of issues is prepared. This can be collected during the project or polled for (verbally or by email) after the project. List of issues is disseminated before the meeting. No names are mentioned. Not in the list and not at any time during the post-mortem ...


4

Six to no more than maybe 9 people is your sweet spot for facilitating working groups. I would predict having a single sessions with 40 people will yield nothing valuable.


3

If the meeting will be just about sharing the results of the questionnaire and the next steps of the product (In other words no interaction with the attendees other than the regular Q&As in any meeting), then it wouldn't hurt to hold the session for the entire team, after all it'll be a way to convey how transparent are you as a management team. If the ...


3

The Scrum team alone cannot solve every impediment. It is a good idea to have some kind of escalation path for issues that are outside of the control of the team, but are recurring and damaging. As a Scrum Master I would often look to escalate this kind of issue using a reporting process. For example, I might produce a sprint report that says something ...


2

A retrospective should not ban topics. And a retrospective must not waste people's time, either. With that said, what you could do is categorise the retrospective items according to different influence categories: Items the team can change Items the team can influence Everything else / Items the team needs to accept Once you have done that, the team ...


2

Try "Project Review", or, "Debriefing" From Wikipedia, the free encyclopedia Debriefing is a process of receiving an explanation, receiving information and situation-based reminders of context, reporting of measures of performance, and/or opportunities to further investigate the results of a study, investigation, or assessment of ...


2

I would encourage you to sit with your team (perhaps in the retrospective) and take a look at the values in the Agile manifesto: http://agilemanifesto.org/ Customer collaboration over contract negotiation is something to consider spending some time on as a team or selling to your stakeholders. You may benefit from holding stakeholder demos more frequently. ...


1

If the same impediment is being raised Sprint after Sprint, that brings up a few questions. Is someone actively working on resolving the impediment? Maybe it can't be resolved within the Scrum Team and maybe it can't be resolved in a Sprint, but what is being done to minimize its impact and ultimately resolve the underlying issues? During Sprint Planning, ...


1

Censoring an impediment from the retrospective doesn't solve it. As it looks to be a major impediment that's blocking the team, maybe it's worthwhile to arrange a separate meeting to analyze the problem to get a shared understanding and find a way out of the impediment? The advantages of planning a specific meeting are: You can focus on the impediment and ...


1

Wrong purpose The most common problem is planning it as a blaming session and not as a meeting to come up with a plan to never repeat a mistake. Or, in the rare case it's about a success: Plan it as a way to get to the root of why we succeeded, and how to repeat that routinely. Placing the blame To be successful, these sessions must not be about blaming (...


1

Your thinking assumes several fallacies which have been evidenced time and time again. The idea that software engineering is accurately estimable (it's not, estimates merely become more accurate as we progress towards completion). A healthy backlog of work with some basic estimating and a maintained burn-up chart would have shown that from the start. The ...


1

I also think David got the answer right. But to add a little. Post-mortem is a common term for this activity that is now understood by many. The word's actual latin meaning is less important than the perceived usage of the term from the medical world, just within a project setting. This is always the issue of borrowing a words usage rather than it's meaning. ...


1

Yes. Post mortem applies. The SUCCESS was an artifact of the life of PM process, but after the work's complete, that process is over ... you killed it to bring home a success ... in the same fashion that a hog is killed for great bacon.


1

would be good or not to keep such expression only for failed projects? Like others my perspective is that the phrase you use is fairly unimportant as long as everyone understands what it means within your organisation. That said, while I don't think 'post-mortem' really holds connotations of death in a business context I do think it is generally used to ...


1

My thoughts and experience is as follows: 1. We use Post Mortem meeting when there are high production incidents. We meet and discuss how the issue happened and what are all the prevention and improvements we can do to avoid the same in future. It is a kind of more to understand and avoid in future. 2.We use Lessons learnt for the successful projects ...


1

Based on my experience managing teams and working through sprints at companies of multiple sizes, it seems that if you use the term 'post-mortem' to describe a conversation had at the end of a project (successful or not), your colleagues will certainly know what you mean. That being said, the term 'post-mortem' does indeed have associations with a death, or ...


1

The cause of bug is a very important metric. I generally name is as "Resolved As" with values: Code Fix, Environment Issue, External Entity, Bad Data, Design Gap etc. There is no blame game here as only the team lead should be allowed to categorize it. QA and Devs should not be setting the Cause. End of the day it is useful to know that ...


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