The Agile Skills Project aims to help all members of Agile software teams improve their skills. First, we will identify skills that seem important to us (the Skills Inventory), and we'll create a template for measuring one’s skill level. The Skills Inventory will be a community-owned reference, and welcomes member contributions.
The Agile Skills Matrix is a two-dimensional representation of skill categories and skill levels. We expect the Matrix to evolve. What we describe here is our current, best understanding of the major skills required by Agile software development.
We have identified seven primary skill areas which contribute to effective Agile software development. Team members who possess skills in all these areas will be better equipped to fully participate in the life of an Agile team.
Agile teams must share a vision of what they are working to achieve; the business problem they are trying to solve. When a developer understands the problem domain, they can help the Product Owner evaluate upcoming features. Understanding of the product is the first step to creating a fully cross-functional team.
Teamwork is the heart of Agile software development. A truly collaborative team shares all its information freely. They share their individual knowledge and skills by working closely with their teammates. Teammates who fully rely on one another become much more effective as a whole, yet simultaneously increase individual skill levels.
The purpose of any software development effort is to create features that deliver business value. A good Agile developer will focus on delivering that value. They do not add complexity just to make their program ‘cooler’. Instead they will base their work on business priority. They produce a steady stream of running, tested software with real business value. They will build only what is needed to solve today’s problem, knowing that building too little or too much is waste.
Any highly productive enterprise is founded in learning. Practitioners in an effective agile team view everything they do as an opportunity to learn. Every step is an experiment intended to make real progress, and to clear our vision of what to do next. We accept and embrace the fact that when a task is done, we'll see better what we should have done. That helps us see what to do next.
Those on an Agile project strive to know the state of their code and the state of their project. They do not share their work until they can prove it functions properly and is well designed and implemented. They report progress based upon the actual rate at which fully tested features of real business value are being created.
Developers understand, and choose from, many possible technical ways to satisfy business needs--choices that reflect a craft that balances design, use, and support. They provide the technical underpinnings that enable us always to move forward at a steady pace. They do this using principles of truly simple design, combined with a grasp of technical debt and the means to keep it under control. They use the best techniques for keeping the design under control without excessive work or rework.
An Agile team member seeks new ways of doing things, while keeping existing skills as sharp as possible. They know that ours is an ever changing world and they strive to be prepared to take advantage of anything new. They are both introspective and aware of what's going on around them, be it in the team, or the larger business context. They will take action to fix things that aren't right, and to help those who are in trouble.
Having created a concise list of the skills important to Agile development, we must now turn our attention to assessing one’s level of attainment. We recognize that individuals will differ in the ways they best learn new ideas and skills. Therefore, we are not prescribing any particular learning mode or vector, but instead wish to focus on outcomes and abilities.
We suggest the following hierarchy of skill.
Individuals at this level have been exposed to a skill, but do not yet have firsthand experience with it. This may come through reading or conversation, through a formal class or casual presentation at a local user's group.
A training course should provide at least this level of attainment.
At this level, one has practiced the skill in a ‘safe’ environment. They may have taken a course with hands-on exercises, or recreated the examples from a book. The Novice level represents the first big step from abstract to concrete. A wise organization will not let a Practitioner loose on their own. They do not yet know what they do not know. They do not yet know what they do not know how to do.
A training course with a sufficient hands-on component could provide this level of attainment.
A Journeyman is known to possess the specific skill. They have demonstrated a practical knowledge of the skill in various environments. They can work on their own, or to increase the competence of a team. A Team member of a lower skill level will learn from them, a team member of a higher skill level will recognize their expertise.
One cannot be taught to be a Journeyman, one can only learn it. Regardless of the skill category, maintaining Journeyman status, one must practice their current techniques and seek out new and better ones.
A Master must possess unquestioned competence in the particular skill. They know it cold; it is second nature to them.
But, it does not stop there. To be accepted as a Master, they must also accept the additional job of bringing up the skill level of their team mates. They do this in several ways.
They serve as an example of proper practice. If you want to know how it is done, observe a Master.
They partner with other team members and actively share their knowledge and experience.
They seek out teachable moments. When asked a question, they prefer to engage in a dialog that will lead the questioner to an answer, rather than making a pronouncement.
To be a Contributor, one must have added to our community’s understanding of how to practice our craft. Contributors bring new ideas to light. They develop and evaluate new techniques. They are the silverbacks and young turks, who advance the state of the art. They may be seen as today’s heretics.
The Matrix was designed with three principle uses in mind.
Since the Skill Levels relate directly to the achievements of individuals, we believe this will be the Matrix’s primary use. A team member will be able to compare their skill level in each of the Pillar categories and use the result to identify areas needing improvement. The Agile Skills Project will include suggested learning experiences, including ‘technical quests’ designed to lead the student through a series of developer challenges designed to increase their skills.
Teams will be able to assess themselves as a unit, as well as individually. They could then use the result to plan training or even to identify additional skills to look out for when adding new members.
We envision using the Matrix to provide an unbiased look at the scope and depth of training courses. This would be particularly valuable for courses that purport to provide comprehensive education.
Input for this assessment could come either through examination of course outlines and learning objectives or based upon reports of course attendees.
There has been much discussion in the Agile developer community regarding certification. It is no secret that the Agile Skills Project was started as a reaction to the desire by some to create some form of developer certification. By comparing a certification’s requirements to the matrix, the community will be able to judge the certification’s true meaning.
The Project stands fully behind the Agile Alliance’s position on certification. It should be skills-based and hard to achieve. To that end, we intend to evaluate any developer certification against the Matrix and publish the results.
The Project will neither endorse nor condemn any certification. We will do our best to show what Pillars it covers and to what depth. The Wizard was wrong, it is not diplomas we need.