Agile Developer Skills Workshop--Day Three

Today is the culmination of the three-day workshop... I think the team has really gelled with a common purpose and shared values. I had to leave early, so will only report on the morning--but stay tuned because soon we'll have something sufficiently well polished that we don't have to hide our candle under a basket.

So, with the caveat that the group may quickly change direction (we're all agile, right?), I'm happy to report on where I think we're going. We'll be creating the Agile Skills Project, an ongoing, open, and not-for-profit entity that will do the following. But first--who is the "we" that follows? Assuming that you're at an experienced practitioner level, it probably includes you:

• create an "agile skills inventory"--a list of skills that are important to being a good agile team member (note, this is not just for coders), a definition of those skills, and even links to existing learning materials (books, web sites, courses, classes) that may help one acquire these skills. These skills will be mapped to the Seven Pillars, and specific ones will be selected as fundamentals that every well-rounded agilist should know


• provide a way for individuals/teams/orgs to self assess against the inventory--this can be an index into where they should focus self improvement efforts, or what kind of help to seek, paid or unpaid.


• recognize progression along the agile skills inventory--the intent here is to celebrate the successes we make in our life-long learning; the risk would be that people could misconstrue this as an endorsement of a particular competency, which it is not. We see several levels of progression through a skill: exposure/awareness, attempted, successful execution, refined execution, advanced the state-of-the-art. From the "successful execution" level and up, there would be third party verification that the skill was indeed performed correctly.


• characterize learning materials--we'll be able to map existing courses, certifications, conference sessions, books, etc. back to how much they cover the agile skills inventory. This will give a nice "nutritional content" to these learning materials, and help people see the objective value these materials provide


• collect experience narratives--at some point, all this work should tie back to the correlation between delivery and skills. This will provide data that correlates successes and failures to how we do the work.


• review experience narratives--With experience narratives, we'll be learning from practitioners in the field, and be able to improve the Agile Sklls Inventory accordingly. As a nice byproduct of experience narratives, we'll have a paper trail of what progress individuals have made in their learning journey.
  

Agile Developer Skills Workshop--Day Two

So imagine an organization, run by the agile community (or a large subset of it--at least the people that have shown a trustworthy commitment), that is in charge of defining the set of skills we find useful in being a member of an Agile Team. This group would be involved in:
-defining an Agile Skills Inventory (e.g., Active Listening, Story Splitting, Test-driven development)
- providing a repository for reference courses
- defining self/peer assessments
- defining a quest ecosystem
- experience reports
- characterization of external courses (for a fee?)
- rating of trainers for a particular course

Well, this is what we're trying to imagine, and here's how we attacked it today--in several sessions. The group asked me to help facilitate (thanks, Pat, it was a great honor! though I'm not sure if I did in fact keep us on task):



We pondered what value this system would produce, so we talked a bit about supply and demand:




Then we talked about the idea of "a quest ecosystem", or points, or merit badges, or achievements, and ultimately thought it could be called tokens. Basically, we'd like to acknowledge the work people do to improve their developer skills:




Then we tried to clarify what this Agile Skills Project would be all about:




Essentially, what we see right now is that the community would own and maintain the ever-evolving definition of agility, then certify training organizations/courses/study material against the standard. To help developers, these 'certifications' would characterize the courses; alternative free methods would also get characterized as well--so then it's up to the developer to take a course or teach oneself.

To further help the community, we'd have a 'token' system, by which team members could go on learning 'quests' or exercises, which would be recorded in a web site as an experience report. This report would be rated by peers and generate points for both the reviewer and reporter. These points would not be fungible, would have no external worth, but could be used to help people categorize their own strengths and weaknesses, to prioritize further learning quests.

One of our group members took some of the initial 7 pillars work (technical excellence, collaboration, product understanding, supportive culture, business value, confidence, continuous self improvement) and made a wordle picture:

Agile Developer Skills Workshop--Day One

Today a group of interested and interesting folk (I'll get a list of the 14 attendees soon) met in Ann Arbor to discuss the Agile Developer Skills idea. We started with a quick outline that I hoped would move us from a group to a team--a list of what motivated us to show up at the meeting, a reality check on what our goals were and if our sphere of influence was sufficient to make it happen, a list of customers, and then a discussion of a business model that could sustain this system.











We soon moved into a mindmap of our various motivations:

























Then we brainstormed on a list of personas that may be our "customers" or stakeholders.

Then we discussed possible goals / to-do items / outcomes of this workshop.

The next steps are to filter the list of proposed outcomes and to review, in detail, potential "generally accepted curricula" that could be used in various courses.

Agile Developer Skills Workshop--Homework

In the wake of announcements from the Scrum Alliance and Microsoft on a "Certified Scrum Developer" program, that would cost around $4-5k per developer, Ron Jeffries and Chet Hendrickson are hosting a discussion on how we, as a community, can support skills development for developers/agile team members. In preparation, I hosted an open space discussion on the topic at Agile Tour Besançon, and a parallel session ran in Agile Tour Philadelphia. The community has long resisted any developer certifications, for many reasons:

• existing schemes don't seem to measure the most important skills
• certificate possession doesn't seem to correlate with skill
• certification has been expensive
• etc.

When I spoke with other developers, the following topics came up:

• how is any test/class going to show if I'm good at my job?
• who is going to pay for the test/class?
• why should the Scrum Alliance or Microsoft or WAQB or any company be able to define agility?
• what happens if people get the cert and I don't?
• etc.

I also had a nice conversation with Laurent Bossavit about the topic. He suggested that at the workshop we ban the word certification--that way we'd have to reveal the motivations for wanting the program at all. He feels like certifications are a replacement for a system of trust--but once money gets thrown in, we need a way to justify the system--a way to explain what people are paying for. One motivation for creating a system would be to show who in the community is worthy of emulation... to show what behaviors are valuable, what practices are effective. In any case, this system should be community owned, democratic, and should value/reward life-long learning, while still fostering innovation towards better ways of developing software.