13 Reflection on Kernel
13.1 Validity of the Kernel
What we have shown in this part is one single case of using the kernel, i.e. we walk through how Smith’s team progressed through all the states in the kernel. We can say that the kernel is valid for this case, but does it work for other potential cases? To validate that, we would need to apply the kernel over a broad range of endeavors. As of today, we have done this both through academic classes and real world industrial projects. As of 2017 we have got no proposal for removing any elements from the kernel. However, we have got proposals of adding elements, and such additions will probably happen as time goes by but being conservative they must be very well motivated.
13.2 Applying the Kernel Effectively
There are two important approaches that Smith applied to run his endeavor effectively, namely the kernel alphas and the facilitation games, such as using cards.
Let’s revisit alphas. Software development endeavors are complex multi-dimensional endeavors. Each alpha addresses the complexity from a particular dimension, such as from the Opportunity, Stakeholders, Requirements, Software System, Work, Team, and Way of Working dimensions. Each comprises a lifecycle of its own. Each dimension is based on some underlying theory. For example, the Team alpha is based on the Tuckman model of team formation and performance; the Stakeholder alpha is based on works on stakeholder engagement, and so on.
Even though the alphas are separate, they are not independent. They are just different views of the same endeavor. As such, in an endeavor the kernel alpha states progress in waves as discussed in section 12.2. We have to make moves that take the endeavor from one set of states to another set of states, and the balance is achieved by doing enough on each dimension to be able to progress all dimensions. This wave like progression acts as a reference for detecting anomalies, as we have discussed earlier in section 12.3. If some dimension, e.g. Software System or Stakeholder dimension, progresses much slower than other dimensions, it would be a cause for concern. Waterfall projects can fall into the error of producing a demonstrable Software System too late. Agile projects may fall into the trap of not seeking early stakeholder feedback and consensus. Thus, the kernel alphas provide a simple but yet holistic progress and health check.
The second approach is the facilitation games we introduced in chapter 9. Software development is a complex endeavor with participants coming from different backgrounds and having different intent, and thereby could have different ideas of how best to run the endeavor. Although the kernel alpha state cards and checklists provide descriptions of what each alpha entails, there is still that important work to ensure that the alpha are being used and understood. As such, the cards are important consensus facilitation tools.
Software development is a cooperative game, and having consensus amongst its participants is crucial for success. Just having a prescribed kernel alpha definition is not sufficient, we need to get them into the hands of the participants and to have them used in everyday conversations. The games discussed in this part of the book are cooperation games and are about consensus building, aligning different people’s understanding and thereby work towards a common goal, which is the success of the endeavor. There are other games supporting the actual development work
In this part of the book, we have shown how a team conducted a development endeavor using minimum explicit knowledge. This minimum explicit knowledge is captured in the Essence kernel, and in particular the alpha state cards. However, the team’s way of working was not static. For example, they added an additional alpha (e.g. requirement-item), and they added some additional checklists (e.g. to Requirements Addressed state) to help Tom understand when this state was achieved.
As we described teams have to add practices to the kernel to get a complete way of working. Often, many teams don't describe them but keep them tacit. When such teams grow in numbers, and as new members join and others leave the team, it becomes quite difficult, especially for the new members, to understand exactly how the team functions.
Even if a team did make their way of working explicit, it is another thing to structure it in a way that is easy for the team to use and improve as they learn. So, how does one make the way of working easy to use and improve as you learn? In the next part of the book we will demonstrate how to achieve this goal through the idea of explicit practices.
Recommended additional reading
- Alpha State Card Games- https://www.ivarjacobson.com/publications/brochure/alpha-state-card-games. Here you will find the games described in this part developed in some more detail. This reference should be used when the reader is looking for more information about the games.
- Ng, Pan-Wei. "Making Software Engineering Education Structured, Relevant and Engaging through Gaming and Simulation." Journal of Communication and Computer 10 (2013): 1365-1373.
- Graziotin, D. and Abrahamsson, P. “A Web-based modeling tool for the SEMAT Essence theory of software engineering.” J. Open Research Software 1,1 (2013), e4; http://dx.doi.org/10.5334/jors.ad.
- McMahon, Paul E., “A Thinking Framework to Power Software Development Team Performance”, Crosstalk, The Journal of Defense Software Engineering, Jan/Feb 2015. http://www.crosstalkonline.org/. This paper discusses specific features of Essence that can help teams improve performance in ways previous frameworks have fallen short. Recommended to teams that are using other frameworks and are looking for ways to improve their performance.