The Dunning-Kruger Effect, encapsulated in phrases like “Other people’s work always seems easy” or “The more I know, the less I know” (or as Socrates put it, “I know that I am intelligent because I know that I know nothing”), highlights a peculiar aspect of our perception, scientifically termed the Dunning-Kruger Effect.
The Team Competency Matrix is a straightforward tool for determining the set of skills within a team based on specific needs. We can use this matrix to assess whether all the skills required for a project are present or if the team is actively developing them.
In teams, it’s crucial for all members to share their skills with others. Relying solely on one team member possessing a particular skill can be risky.
Imagine a scenario where a team member has an accident; if they are the sole possessor of certain project-critical skills, it could be a genuine catastrophe for the company.
Working with the matrix starts with identifying the skills required for the project and the expectations for each of these skills.
Building this skills matrix is quite straightforward because it is simple and specific. This matrix provides a holistic view of the team’s skill set.
The method of prioritization known as the Walking Skeleton emerged in the early 2000s, championed by Dr. Alistair Cockburn, an expert in agile software development who described it as:
… A tiny implementation of a system performing a small end-to-end function, it avoids using the final architecture but ties together the fundamental architectural components. Subsequently, the architecture and functionality can evolve in parallel.
The Walking Skeleton represents the embodiment of your basic architectural concept. It’s not a mere sketch; it’s a genuinely executable and deliverable product that must be accompanied by tests.
Due to the nature of this method, the Walking Skeleton is utilized to prioritize features in an MVP, determining which ones are absolutely critical for the product to function. Sometimes, the Walking Skeleton may be smaller than a full MVP, but it prioritizes essential features.
How does it work?
All features are laid out in the form of columns, acting as vertebrae, and stories hang down like ribs. This representation visualizes the importance of user stories within specific features and focuses on implementing one set of stories at a time.
Once you’ve established the foundation and listed all your core features, you can start prioritizing stories in each rib. The higher the priority of a story, the closer it is to the backbone, making it more crucial and relevant. Stories towards the end are less important.
After placing the stories, you’ll see the minimal implementation of your product at the top of the “Story Map.” This is what Dr. Alistair Cockburn refers to as the “Walking Skeleton”: a very minimalistic but functional product, typically ready for user testing.
When to use it?
The primary goal of the Walking Skeleton model is to ensure that the MVP eventually “walks,” meaning it works according to requirements. Therefore, when evaluating features using this model, you’ll need to determine the following:
Everything necessary for the system to function.
Features that must be there according to requirements.
Features aligning with business goals and values.
Features that have passed testing.
By choosing and implementing these features, you’ll end up with a func
Kaizen, or 改善 (pronounced kai-zen), represents a Japanese philosophy and practice that centers on the continuous improvement of production processes, development, supporting business processes, management, and all aspects of life.
The concept of Shu-Ha-Ri comes from the Japanese martial art of Aikido.
Shu (守): The first stage, which means that one must memorize everything exactly as the teacher shows. It requires many years of training, or else there will be no foundation for moving on to the next stage.
Ha (破): The second stage, where the learner reflects on their actions, changes the rules, tries to break them, and builds a new system of their own rules. They also learn new techniques from other teachers. Many try to do this too early, overestimating their capabilities.
Ri (離): The third stage, according to which one needs to free oneself from rules—there are no more rules, only the natural course of things (Dao). “Ri” means to rise above everything that was learned before, to create higher and more general principles.
The Shu-Ha-Ri model can be adapted not only for martial arts but is also an ideal metaphor for Agile team development.
Shu: We strictly adhere to Agile rules. We see that all Agile meetings/ceremonies are conducted, and all rules are followed. For example, the Daily Stand-up does not exceed 15 minutes, and the whole team discusses progress in achieving iteration/sprint goals.
Ha: Now that everyone is familiar with the basic rules, we can begin to improve and make amendments to them. Referring to the example above, perhaps we will review our Daily Stand-ups and change their time, or we will go through each user story instead of listening to each person in turn. Practicing this approach, we can see what works and what doesn’t. Retrospectives will greatly assist us in this.
Ri: We have departed from the “standard” structure and mechanisms and have begun to set our own rules.
The MoSCoW method is a prioritization technique used in many management spheres to achieve consensus on what is most important to stakeholders and consumers.
This term is an acronym, where each consonant letter represents one of the possible priority categories (with the added letters O for better memorization). Thus, priorities are classified as:
Must have – everything under this category is critical and must be included in the product. If something from it is not included, the release is considered a failure. However, this priority can be lowered if there is stakeholder agreement.
Should have – these are important requirements but not critical for the release. These are the first level of “wants,” and generally, in terms of importance, they correspond to Must requirements but are not as time-sensitive.
Could have – these are desirable but optional requirements for the release. Typically, these are inexpensive product improvements. Despite their low importance, this is the second level of “wants.”
Won’t have – these are functional features that are least critical or do not align with the product strategy. They should be set aside or kept in mind for subsequent product releases.
COBIT (Control Objectives for Information and Related Technologies) is a methodology for managing information technologies owned and developed by the non-profit organization ISACA (Information Systems Audit and Control Association). It comprises a set of open documents, about 40 international and …
Scrum teams are self-organizing, self-managing, and cross-functional. Self-organizing teams independently decide how to perform their work rather than following external instructions. Cross-functional teams possess all the necessary competencies to perform the work and are not dependent on individuals outside the …
Agile is not a development methodology but a way of thinking that helps solve three business tasks: satisfy customers, reduce time to market, and lower the cost of changes. In the 1990s, a set of flexible software development methods was …