Look at the following two situations – one coming from implementation of XP and one from Scrum.
Situation 1
The Principle of Mutual Benefit in XP says that every activity that you do as part of software development should benefit all concerned – now and later as well. Any solution should not cost one person / team while benefitting another.
One example where teams struggle to implement this principle is in dealing with the need for internal documentation for code developed (often detested by developers) so it helps potential maintainers of code in the future. While it could benefit future code maintainers (assuming documentation is current and up-to-date), current developers of code don’t like doing it since it typically slows down their development. How will you solve this problem of communication with the future (developers to maintainers) in mutually beneficial ways? In other words, how will you benefit the developers today while helping potential new team members in the future?
Situation 2
One of the teams is implementing retrospectives through a brainstorming session facilitated by the Scrum Master (SM). People are allowed to give verbal inputs on what went well / didn’t go well etc. During the meeting, while team members start giving inputs, the SM finds that they contradict each other, there are arguments between members on specific inputs, and there is confusion and chaos, even forcing some members not to open up at all. In the end, the meeting exceeds allotted time while not being effective as well. The SM feels he implemented the retrospective as a practice to align with feedback as a value and the principle of reflection, but the practice has not worked out as he expected it to.
What is your analysis of the practice used vis-à-vis the Agile / Scrum values and principles you are aware of? Has any value or principle been violated? What are some possible ways to improve this practice aligning with Agile/Scrum values and principles?
Recommended approach / solution:
Situation 1
Following are some ways to address the problem while not compromising on the principle of mutual benefit:
- Writing automated tests that will help design and implement better today and leave these tests for future programmers to use / maintain. These tests serve as roadmaps to the code and how to interact with it. They are a great substitute for detailed written documentation that is typically used (which rarely stays current / up-to-date). These tests benefit the team now and, in the future as well.
- Refactor code to remove accidental complexity and make the code more readable. Has the potential to lower defects today / contribute to programmer satisfaction and makes it easier to understand code for those who use it in the future.
- Use of variable names / other programming conventions that speeds development today and makes code clearer for new programmers as well
Situation 2
While the retrospective may have satisfied the principle of reflection, there is a possible violation of some values and principles. While feedback as a value may have been implemented through this practice, the free-for-all nature of the meeting seems to have led to compromising on a value such as respect for people (and their inputs) and the principle of providing an environment and support for motivated individuals. Given the chaotic nature of the meeting this time, even those who gave inputs this time may not feel like giving their inputs the next time. This could even lead to courage and feedback as values being compromised in the future.
One way to deal with this issue and respect every one’s inputs equally well is to have people provide their inputs on stick-it notes and having them paste them on boards. This way they are not biased by others’ inputs and are free to give their own. You can use one of many tools available for this purpose as well. The team reads all inputs received, when all the members have given their inputs. After understanding all inputs, the SM can facilitate a discussion on assumptions and rationale for inputs, where there are questions. One can use open voting for prioritization of inputs and actions.
There are obviously other ways you can implement retrospective as a practice without compromising on values and principles you have chosen to use. Would love to hear from you on your views on those.
