BENEFIT OF A RETROSPEKTIVE
Retrospectives support further development. Here there is time to promote strengths and develop solutions to problems.
This can include topics of teamwork, technical problems, process deficits, product-specific topics, acceptance, appreciation, communication within and/or outside the team, etc.
PROCEDURE OF A RETROSPECTIVE
The process of a retrospective usually proceeds in five phases:
- Intro: Arrival, clarification of the retrospective's objectives, possibly reviewing the measures of the last retrospective
- Collect data: What went well?, what went bad?, what questions and ideas are there?, who can/would I like to thank?
- Gain insights: Analysing strengths and problems and developing possible solutions
- Developing measures: SMART objectives that help to improve work processes.
- Checkout: Feedback on the retrospective
- How we doing?
- What's going well? Why?
- What's going bad? What's wrong? Why?
- Are we proud of our product?
- Would I do this again?
- What are the risks?
- Do we have all the necessary information?
- What do I need to master the task?
- What hinders me? What do I need instead?
- Who can I say "thank you" to? Who has supported me?
FACTORS FOR A HELPFUL RETROSPECTIVE
Of course, it is often helpful to analyze events of the past in order to learn from them for the future. At the same time, we humans usually know very well what we do not want. However, it is not easy for us to formulate what we want "instead". A fear-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 GOD TO LAUGH... MAKE A PLAN!
Life is change. Change is part of it and absolutely inevitable.
This also applies to project work. The further apart the beginning and the end of an undertaking are, the less reliably we can describe what will happen. We can make the clearest statements when we are close to the implementation and have as much information as possible.
For this reason, the term "last responsible moment" is used in the agile environment. This means to wait as long as possible 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 a while. Our preferences have changed, the circumstances have changed, we have learned and are going in different directions than we previously imagined. All "old" plans become useless.
For this reason, it is more sensible to repeat plans iteratively, in smaller cycles and to go into more detail. In this way we get more and more information and can respond to changes without wasting time.
The cynefin model tries to make the complexity clear.
You often do not 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-and-effect can be analysed and activities can be planned. This also includes, for example, the construction of aircraft.
Software development and inventions are counted among the complex activities. Cause-and-effect can usually only be determined afterwards. Emergent practices help here.
Chaotic states can be found in a fire or in experiments. Here a cause-and-effect principle is not visible in the system. In most cases completely new, innovative practices are used.
Agile estimation methods mostly use abstract estimation methods, which is faster than conventional estimation methods. The human brain finds it easier to classify things into "smaller" or "larger than" a reference value than to define more detailed differences.
PAINTING THE APPARTMENT
This becomes clear in the example of "painting the apartment". Conventional estimation here likes to assume how many square meters each room has and how long it takes to paint it. There are two main problems. On the one hand, a time estimate always depends on the skills of the craftsman. At the same time, the number of square metres does not tell us anything about the general conditions, such as the condition of the walls, materials etc. If a craftsman other than the appraiser has to paint the apartment, the result will certainly differ from the estimate.
In abstract estimation, the estimators can agree on how large the rooms are in relation to a reference value. E.g. the kitchen is the reference size with 10 sqm (= 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 bathroom is only half as large, but has many obstructive pipes (= 1 point + 1 "problem" point). This assessment of the apartment will not change, no matter which team is competing. A team with many apprentices will probably take longer than one with long-time experienced staff.
How long the painting will take can be determined by the velocity. Velocity is the number of points the team gets in a best time. time. And depending on the composition of the team, a different velocity will occur.
In an agile environment, prioritization is given an important role. It is important to do the most important work first. This means that we can use these results more quickly and also have the freedom to finish projects earlier without a major loss of value. Using the example of "painting the apartment", it would make sense to renovate the living room in front of the storage room.
A simple prioritization method is that of Stephen Covey or, originally, Eisenhower.
Automated testing is an important practice for improving and maintaining quality. Changes and code extensions must be tested in such a way that existing features still work as they did before the change. Test automation makes errors quickly visible.
Pairprogramming (= working together in pairs) is an important practice that comes from "eXtreme Programming". The cooperation leads to quality improvement, because according to the 4-eye-principle errors are found faster. Furthermore, pairprogramming 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 IS REFACTORING USEFUL?
Agile working means permanent refactoring. This keeps the source code acidic and prevents it from becoming obsolete. Regular refactoring keeps the effort curve low and serves to combine feature and quality.
This keeps the source code easier to understand and makes it easier to extend.