Remember that a specialized tool, such as Agile Retrospectives for Jira or Confluence, can help you to easily hold engaging and dynamic sessions as well as saving time when collecting and analyzing feedback. You can take full advantage of your sessions, make your team's time worth and keep complete transparency, visibility and accountability with this add-on. Start a free day trial in here. In conclusion, there are important differences between Post-mortems and Retrospectives and, aside from using the correct word, understanding their structures is truly useful.
And specifically picking-up on the Retrospective sessions and other Agile methods will help you refine your project management skills. A Post-Mortem is a full-scope review of a project, which is delivered after its completion. The result must be an array of action items that must be implemented to fix or improve the raised issues. AAre you adopting or looking to improve your Agile practices? Is your team remote? We focus on making communication more effective and easier for remote teams.
Topics to check: Key differences between Post-Mortems and Agile Retrospective sessions How to get started with Agile Retrospectives The best tools for useful Retrospective sessions Key differences between post-mortem and retrospective sessions They might sound similar, but be careful not to confuse them: Post Mortems are not the same as Retrospectives. Getting started with retrospectives It all starts with keeping regular sessions with your team.
A standard format that might be useful for you is: Set the stage Greet each attendant and be mindful about their reactions. Gather data The team needs to understand its own vision about the last Sprint. This can be done by asking each attendant the following questions: What went well? What did not go well?
What could we improve? The visible agenda serves as a reference point for topics that have already been covered so the chance of doubling up on something is minimized. Deliverables Recap: This outlines the scope of work or contract agreed to by both the service provider and the client.
I listed those items here. This helps to realign your team with the results as they pertain to the client, the contract and the project as a whole. Did we deliver on time? Was there anything that was grossly over or under estimated? This takes some digging, but the information you can extract is worth it.
For certain projects I go through months of emails, meetings and calendar invitations to compare the two. Be as specific and detailed as possible, with annotations about how things actually transpired. General Discussion: No project post mortem is complete without allowing everyone to get at the meat on the bone. In Creativity Inc. Again, feel free to adjust these prompts accordingly to fit your team.
Meeting Recap: Eventually, depending on how in-depth the general discussion goes, the meeting will reach a natural stopping point. Thank everyone for participating and inform them a meeting recap will be on the way.
Then actually send a meeting recap. The whole point of a post mortem is to make the next project better. Formulate the findings into actionable goals that everyone can work toward.
Sometimes these even come as a pleasant surprise. In a recent post mortem for one of our projects, we realized that content creation had been an issue. We had recently done information architecture for a separate client and realized that if we foresee content being an issue, it would behoove us to bring our content modeling process into the fold much earlier. This way various departments such as design or development can access the content model as a central hub when needed. We seemed to have more success during our own team meetings on Sunday that during the lab sessions.
In most meetings the action items got completed in a timely manner but our organization could have been much better. Sometimes it was difficult to organize six different people doing six different actions. We then get into the next topic of communication and coordination. One example of this difficulty in communication occurred during the thanksgiving break in which lack of coordination posed a difficult problem in getting the deliverable finished on time.
Communication during meetings and emails were to the point and worked well but the lack of communication outside of meetings cause the greatest problem. Group Dynamics: Overall the group chemistry was very good. We went through team meetings smoothly and did not have any significant problems.
All group discussions ran smoothly and all team members were respectful to other team members. Training: We had a couple of successfully training sessions but found that more in depth training sessions could have been useful in the overall software engineering process.
This is especially true with respect to the networking skills. At first, all members of the team were questioned about their abilities in certain topics. After that, the most weak topic found among the group was the User Interface, especially with the use of swing, and networking. Two small informal training sessions were created to help enhance the understanding of each of these topics. Those session went rather well and had pretty respectable results. Miscellaneous: We are very happy with our final design and stage 1 implemenatation.
Our design was well thought out and crafted thoroughly. Overall, we didn't invest any significant extra amount of time. Management was not a problem for this group. Since we were only a group of four people, our organization was very flat, meaning decision-making was almost always done by consensus. This allowed us to be flexible with assigning work to people, and one area our group did very well in was the distribution of work.
When one person was assigned too much, it was common practice for another team member to step up and offer to take part of his workload for him. Things like this raised group morale and productivity. Another practice that made us more efficient was putting the action items on the web page after each class meeting, so everyone always knew exactly what he was responsible for and when it was due, and he could find that information online.
One area we didn't do quite so well in occurred when tasks were mentioned that needed to be done, but no one was specifically assigned to do them.
An example of this was nametags. For the first four weeks of class we had an action item that said, Get nametags, but no one was responsible for it, so for four weeks we went without nametags.
From the nametag experience we learned the importance of not only specifying what needs to be done but also specifying who needs to do it.
It was a lesson that will be valuable in the future, and we are glad we could learn it early on from a simple thing like nametags, instead of not learning it until the end of the quarter and suffering for it.
The small size of our group meant communication between members was not only easy, it was unavoidable. There was seldom anything that one person was working on that the other three did not know about. Email was our primary method of communication and we used it to send completed assignments back and forth, as well as post things to the web in places like our message board and the action item list. However the bulletin board crashed in the first few weeks of class so we mainly relied on email and the action list after that.
This team was excellent at getting the deliverables done before the deadlines were imminent. One of our goals at the beginning of the quarter was no all-nighters, and since we got all of our deliverables done with time to spare before the deadline, that eliminated the need to be up all night the day before something was due. While we all had certain nights when we worked later than we wanted to, the fact that we needed no all-nighters was very encouraging. The only time we even came close to an all-nighter was the night before stage 1 was due, and that ended at the reasonable hour of AM.
Towards the end of the quarter we started using instant messaging to communicate back and forth. This was invaluable when we started writing code. Instead of emailing someone to clarify a question and waiting half an hour for them to check their mailbox, questions were instantly answered and confusion was kept to a minimum. We regret that we did not start using instant messaging sooner.
0コメント