What is Agile Retrospective?

Defination: An Agile retrospective is a meeting that's held at the end of an iteration in Agile software development. Retro event occurrence depend on iteration definition by Scrum Master and Team. During the retrospective, the team reflects on what happened in the iteration and identifies actions for improvement going forward.

Questions to be asked: Each member of the team members answers the following questions:

• What worked well for us?
• What did not work well for us?
• What actions can we take to improve our process going forward?

The Agile retrospective can be thought of as a "lessons learned" meeting. The team reflects on how everything went and then decides what changes they want to make in the next iteration. The retrospective is team-driven, and team members should decide together how the meetings will be run and how decisions will be made about improvements.

Environment of Retro: It is very important that Retro atmosphere of honesty and trust is needed in order for every member to feel comfortable sharing their thoughts. Norman Kerth's work at the turn of the millennium was highly important to the development of Agile retrospectives and retrospectives in general. Kerth's prime directive states, "Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand." Because Agile stresses the importance of continuous Improvement, having a regular Agile retrospective is one of the most important of Agile development practices. 

The Ninth Agile principle outlined in the Agile manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." A framework, such as the one below, can be used to provide structure and keep discussion during the retrospective focused.

Event Steps: Following are the Steps to do Regular Retrospective Event in Agile Scrum Project. 

1. Set the stage - get the team ready to engage in the retrospective, perhaps with a warm-up activity such as Plus, Minus, Interesting (5 minutes)
2. Gather data - create a shared picture of what happened during the retrospective (10 minutes)
3. Generate insights - discuss what was successful and identify any roadblocks to success (10 minutes)
4. Decide what to do - identify highest priority items to work on and put measurable goals on those items so they can be completed (15 minutes)
5. Close the retrospective - reflect on the retrospective and how to improve it, and to appreciate accomplishments of the team and individual interactions (5 minutes)

ref: http://searchsoftwarequality.techtarget.com/definition/Agile-retrospective

Upfront Thinking Is Like Insurance

Insurance is great for all sorts of things. I have health insurance in case I become ill or injured. I have auto insurance that will repair or replace my vehicle if it's damaged. It also protects me in case I am involved in an accident that harms someone else. I have life insurance so that if I die, my wife and daughters are taken care of.
These are types of insurance I've chosen to have. There are other types of insurance I've also chosen not to have. For example, I've personally chosen not to have dental insurance. Most years that works out great for me. But there are some years when I have a big bill and wish I'd paid for the insurance. But, overall, I've been happy with that decision.
Similarly, every time I buy a plane ticket online there's a little checkbox asking if I want to buy travel insurance. I think it covers me in case I get sick right before a flight or something like that. I've never bought that and I've never regretted it. I've also flown over 2 million miles. So forgoing that type of insurance has also worked out well for me.
So insurance is great. I can't imagine going without my health insurance. But other types of insurance can be thought of as calculated gambles, which is exactly what they are. And sometimes those gambles pay off, sometimes they don't.
We can think of upfront thinking on development projects in the same way we think about insurance. Like insurance, upfront thinking is a way of paying a little today to avoid paying a lot tomorrow.
Upfront thinking on software projects can take a number of forms. It can be someone thinking about the architecture of the system. It could be a UI designer sketching wireframes. It could be an analyst building detailed scenarios and confirming all manner of edge cases conditions through workflows. Or it could be a database designer thinking about the structure of the database. I'm not saying any of these are bad (or that they're good). They are merely examples of upfront thinking.
Some projects will benefit from some amount of upfront thinking (although perhaps not all forms at once that I've just listed), just like many of us benefit from having some types of insurance.

How Much Upfront Thinking Is Enough?

An important consideration is how much upfront thinking is enough. The best way to determine this is, unfortunately, in hindsight. But use the level of upfront thinking you do on current projects to help you decide how much to do on future projects. Here's how ...
Suppose your team finishes a project and they never had to reverse a decision. Every decision was made perfectly the first time. I'd say that team overinvested in upfront thinking. They over insured.
Consider instead a team that finishes their project and only had to reverse one decision. But it was a major decision and caused a total re-architecting of the system. That team underinvested in upfront thinking. They underinsured.
Finally, consider a team that finishes the project and had to reverse a lot of little decisions. None caused big re-architecting, but there were a lot of little decisions that each caused rework. On their own, each is small. But added together, it was a lot. Again, here's a team that underinvested in in upfront thinking. They were under insured.
So, as projects progress, evaluate whether the team is having to occasionally backtrack on decision and architectural decisions. They should occasionally have to do so. If they never do so, they've over invested in insurance by doing too much upfront thinking. But, if they're backing up too much or in big ways, they have underinvested and should do more upfront thinking.