BENEFIT OF A RETROSPECTIVE
Retrospectives support growth. This is the time to promote strengths and develop solutions to problems.
This can include teamwork issues, technical problems, process deficits, product specific issues, acceptance, appreciation, communication within and/or outside the team, etc.
PROCEDURE OF A RETROSPECTIVE
The course of a retrospective usually consists of five phases:
- Intro: Arrival, clarification of the goals for the retrospective, possibly reviewing the measures of the last retrospective.
- Collect data: What went well? what went badly? what questions and ideas does it give? who can/would I like to thank?
- Gain insights: analyse strengths and problems and work out possible solutions.
- Develop measures: SMART Objectives that help to improve work processes.
- Checkout: Feedback on the retrospective
- How are we doing?
- What is going well? Why?
- What is going badly? Why?
- Are we proud of our product?
- Would I do that again?
- What are the risks?
- Do we have all the necessary information?
- What do I need to master the task?
- What hampers me? What do I need instead?
- Who can I say "thank you" to? Who supported me?
FACTORS FOR A HELPFUL RETROSPECTIVE
Of course, it is often helpful to analyze past events in order to learn from them for the future. At the same time, people usually know very well what we do not want. However, it is not easy for us to formulate what we want "instead". An anxiety-free and trusting environment is an important prerequisite for living openness in a retrospective. A constructive team and error culture is important for this.
ESTIMATION & PLANNING
IF YOU WANT TO MAKE GOD LAUGH - MAKE A PLAN...
Life is change. Change is part of it and is absolutely inevitable.
This also applies to project work. The further the beginning and end of an enterprise are apart, the less reliably we can describe what will happen. We can make the clearest statements if we are close to implementation and have as much information as possible about it.
For this reason, the term "last responsible moment" is used in an agile environment. This means to wait as long as possible with the planning in order to get the chance to have as much information as possible that we need.
We also experience again and again that what is important for us today loses its importance after some time. Our preferences have changed, the circumstances have changed, we have learned new things and are going different ways than we imagined before. All "old" plans become useless.
For this reason, it makes more sense to iteratively repeat and detail plans in smaller cycles. We receive more and more information and can respond to changes without waste.
The cynefin model tries to make the complexity clear.
You often don't need to think much about simple connections. Cause-effect is usually clear. We find these activities in our daily business.
Complicated relationships can be clarified by analytical observation. Cause-effect can be analyzed and activities can be planned. This includes, for example, the construction of aircraft.
Software development and inventions are considered complex activities. Cause-effect can usually only be determined afterwards. Emergent practices help here.
Chaotic states can be found in a fire or in experiments. Here cause-effect principles are not visible within system. Here mostly completely new, innovative practices are used.
agile estimation techniques usually use abstract estimation methods, which is faster than conventional estimation methods. The human brain finds it easier to classify things as "smaller" or "larger than" a reference value than to determine more detailed differences.
PAINTING THE APARTMENT
This becomes clear with the example "Painting the apartment". Conventional estimation here likes to assume how many square meters the individual rooms have and how long it takes to paint them. There are two main problems. On the one hand a temporal estimation is always dependent also on the abilities of the craftsman. At the same time the number of square meters does not say anything about the basic conditions, like condition of the walls, materials etc.. If now still another craftsman must paint than the estimator the dwelling, the result will surely deviate from the estimate.
With the abstract estimating, the estimators can agree on it, how large the areas are in relation to a reference value. E.g. the kitchen is with 10 square meters the reference value (= 2 points), the bedroom is twice as large as the kitchen = (4 points), the living room is three times as large ( = 6 points), while the bath is only half as large, however, has many obstructive lines (= 1 point + 1 "problem" point). This assessment of the apartment will not change, no matter which team starts now. A team with many apprentices will probably take longer than one with experienced employees.
How long the painting takes can be determined by the velocity. Velocity is the number of points the team scores in a best. Time can work off. And depending on the composition of the team, a different velocity will be determined.
In an agile environment, prioritization is given high priority. It is important to complete the most important tasks first. This means that we can use these results faster and have the freedom to finish projects earlier without losing a lot of value. Using the example of "painting the apartment", it would make sense to renovate the living room in front of the storeroom.
A simple prioritization method is that of Stephen Covey or originally Eisenhower.
To improve and maintain quality, automated testing is an important practice. Changes and code extensions must be tested in such a way that existing features still function as they did before the change. Test automation makes errors quickly visible.
Pairprogramming is an important practice that comes from "eXtreme Programming". The cooperation leads to quality improvement, because errors are found faster according to the 4-eye-principle. Pairprogramming also serves the transfer of knowledge. Know-how is passed on in the team, training of new employees becomes more effective.
Pairprogramming promotes communication within the team and increases the fun factor.
Refactoring means changing the internal software structure without changing its behavior.
WHEN DOES REFACTORING MAKE SENSE?
Agile working means permanent refactoring. This keeps the source code sour and prevents obsolescence. With regular refactoring, the effort curve remains low and serves to combine feature and quality.
This makes the source code easier to understand and therefore easier to extend.