What is the Crystal method in agile?
The Crystal agile methodology is an agile framework which puts focus on the interaction among individuals rather than on the processes and tools used. It empowers teams to find their own solutions to problems instead of being confined by rigid methodologies of doing things.
One of the core values in the agilemanifesto is to place individuals and interactions over processes and tools, and the Crystal method is a direct subset of this value. The methodology acknowledges that different teams are bound to perform differently. This would depend on factors such as the size of the team, priority of the project among others. Due to this, the method encourages adaptation as per the team's needs.
The above is given clearly in the two core beliefs of the Crystal agile methodology:
- Teams are enabled to find their own ways and methods to optimize workflows.
- The project team is best suited to determine how to tackle the work on every project, as every project is unique.
Origins of the Crystal agile methodology
One of the initial evangelists of agile, Alistair Cockburn, formulated the Crystal method for IBM in the year 1991. From his research of successful teams, he realized that best practices differed based on the team's conditions.
His focus was hence on developing guidelines for team communication and collaboration as opposed to regulated step-by-step methods of software development to be used across teams. Using these ideas, he came up with the Crystal framework.
The framework has a certain set of characteristics and principles based on the team size that we've explained in the below sections.
Colour families of the Crystal agile method
The Crystal framework is split into different color classes based on team size and project criticality and priority as follows:
-
Crystal Clear
- Applicable to teams of 1-6 people.
- This is when the members are working out of a single workspace on a fixed price, short-term project.
-
Crystal Yellow
- For teams of 7-20 people.
- This is when teams take feedback from real users and automated testing is made use of.
-
Crystal Orange
- For teams of 21 to 40 people split according to skills.
- This is when they are engaged in medium sized projects that last for 1-2 years and there's a release every 3-4 months.
-
Crystal Orange Web
- Also for teams of 21 to 40 people.
- This is when the codebase is continuously evolving and a series of initiatives needing coding are dealt with.
-
Crystal Red
- For larger teams of 40 to 80 members.
- Here smaller teams are formed and divided based on the need and a more traditional software development method is followed.
-
Crystal Maroon
- For teams of 80 to 200 people.
- This is for very large size projects where the methods used are based on the need of the software.
-
Crystal Diamond and Sapphire
- For significant large scale projects which are critical in nature.
- There could be a potential risk to human life involved in these.
Characteristics of the Crystal Framework
The Crystal agile methodology has three characteristics based on the team itself:
- Human powered - This means that importance is placed on the people involved in a project. The various processes need to be adapted based on the needs of the individuals involved.
- Adaptive - The Crystal method isn't a rigid framework but rather one which can be stretched to fit requirements. This means that tools and processes can be modified to fit needs.
- Ultra-light - This means that the framework isn't based on extensive documentation, reporting or management of individuals. There is a transparent workflow between the team and clients and teammates communicate openly.
Principles of the Crystal agile methodology
The Crystal agile methodology is based on 7 key principles which are also sometimes referred to as its properties. We have explained each principle here.
1. Frequent delivery
Regardless of the various factors such as team size, type of project, budget or profit, the priority of the team should be to deliver. So, to keep up with this, the team needs to frequently deliver code that has been tested and is working for real users. This is also useful in making sure that the product is actually something that the users want.
2. Reflective improvement
It's important to understand that there could always be room for improvement. Hence, there is a need to reflect on the performance, see what was done, how, and why. Understand where there is a need for improvement and see what will work and what won't.
3. Osmotic communication
Osmosis means the flow of matter organically. Applying this, Cockburn believed that there was a need for colocation of teams so that information can be perceived by all members, even if they are not actively a part of the discussion.
4. Personal safety
The personal safety aspect means that the environment is open and safe for all team members to communicate their ideas and thoughts without feeling like they are ridiculed. Team members should freely present ideas and talk about problems. Open and honest communication is stressed upon.
5. Focus on work
The seniors or leaders on a project should set out the priorities in a clear manner. Team members should at any time know what comes next and what is to be done at the given time and focus on it instead of constantly switching between tasks.
6. Easy access to subject matter experts and users
Developers should have a link to the real users of the product they create. Qualified people and real users of the product give valuable feedback that the developers can work upon.
7. Technical environment
The work environment should be fully equipped. This means that it should have tools for automated testing, configuration management as well as continuous integration and deployment. Errors and mistakes can be identified quickly without the need for humans to intervene when this is the case.
Originally published here.
P.S. If you liked the above, also check out these blogs on startups and product building:
Top comments (0)