First, two things are fundamental:

1. Ship running, tested software every two weeks, or, if you are a wuss, every month. (DONE == DONE)
2. Reflect frequently on how it’s going, and revise your practices in accord with what you observe. (Inspect and Adapt)

Now then. When you set out to do these things, certain chains of events are inevitable and I do mean inevitable. Here’s one example:

1. To ship done software, it must be tested.
2. To ship done software every two weeks, it must be tested every two weeks.
3. Changes to the software can, in principle and in practice, break essentially any feature anywhere in the software.
4. To ship done software every two weeks, essentially every feature needs to be tested every two weeks.
5. This testing burden increases linearly or worse than linearly with the number of features.
6. Manual testing cannot sustain the two week delivery cycle.
7. Therefore, for a truly successful iterative software project, automated testing is absolutely necessary.

There are quite a few things like this that are just inevitable. There are others that are almost always needed, others that are commonly needed, still others that are sometimes needed.

To call a process “Scrum”, we demand certain things. All of those things are pretty good ideas. Some of them may be necessary to a successful project, even if they are necessary in order to call the process Scrum. I’m more interested in successful projects than I am in the name of the process.

Historically, software projects have had no API. You gave a software team an unchangeable list of requirements and an immutable date. The project was done in phases such that nothing was useful until all phases were finished for everything: analyze, design, code, test. Along the way, the project produced no measurable output and could not be controlled in any useful way.

As the manager became more and more concerned that things weren’t going well, their only available approaches were to add people, which is usually not possible and doesn’t work anyway, or to add pressure, which doesn’t work either.

Incremental projects using approaches such as Scrum offers of course do have an API. They produce completed features which can be counted, and you can control very nicely what gets done by the date just by selecting the features to do next. (You still can’t improve things by using pressure, mind you.)

However, well-crafted incremental projects don’t let the manager control scope: they put that in the hands of business-side people, product planners and the like, who used to be passive –and unhappy– recipients of whatever the software project actually did.

So software managers now have a very odd job to do, if they have a job at all. They are not really able to manage much of anything about the project. The date and scope are set by the business side, the team’s practice is guided by a coach or ScrumMaster, the team makes all the technical decisions, adding people still won’t work, and pressure still doesn’t work.

No wonder they are confused.

Some good people[1], plus Chet and I, met in Ann Arbor the week of October 12 2009, to discuss Agile Team Member qualification. The outcome: The Agile Skills Project.

The Agile Skills Project is a non-commercial resource that will establish a common baseline of the skills an Agile developer needs to have, including a shared vocabulary and understanding of fundamental practices. The Project intends to:

• establish an evolving picture of the skills needed on Agile teams;
• encourage life-long continuous learning;
• establish a network of trust to help members find like-minded folk, and to identify new mentors in the community.

Among the projects we have an interest in supporting are:

• defining an Agile Skills Inventory (e.g. Active Listening, Story Splitting, Test-Driven Development, Exploratory Testing):
• providing a repository for reference courses, interest groups, and other material;
• defining self and peer assessments;
• characterizingof external courses in terms of their coverage of the Agile Skills Inventory;
• defining a “learning ecosystem” including paths of learning, or “quests”;
• offering means for publishing team or individual experience reports;
• supporting community rating of courses or trainers;
• supporting ratings for trainers and courses

The Agile Skills Project is not for profit. It aims to be independent of any specific form or style of Agile, and explicitly welcomes all such forms and related disciplines such as Lean or Kanban. The idea here is to build an inventory of all the skills that can aid an Agile team member, across the board.

Looking at certification specifically, The Agile Skills Project stands in full support of the Agile Alliance position that certification should be skills-based, and hard to attain. At the same time, the Project also exists in support of any and all such efforts, in that it will provide a stable and independent Skills Inventory, against which any proposed certification can be assessed.

I just thought I’d make a page with links that may be worth exploring. If you have some, let me know. I have not explored all of these, nor, probably, have you. That’s why I’m listing them.

Iteration Burndown Google Spreadsheet

Visual Management Blog. Articles and pictures about managing projects with big visible charts and information radiators.

Why Project Managers Can’t Manage Projects. Interesting David Schmaltz article suggesting that project management is literally impossible.

Technical Debt on Your Balance Sheet. Is it possible to monetize technical debt?

Perfect Example of Certification. Who says certification has no value?

Comparing open-source Agile project management tools.

Here are a few links relating to collocation, thanks to Adrian Howard and others. If you know of more, let me know, please.

CSCW 2008 Workshop: Supporting Distributed Team Work

RE challenges in multi-site software development organisations

An empirical study of global software development: distance and speed

Team Knowledge and Coordination in
Geographically Distributed Software Development

How Does Radical Collocation Help a Team Succeed?

Working together in “war rooms” doubles teams’ productivity

George Dinwiddie Collocation Page

Things in the skills development area have changed in some interesting ways. We have room for a few more people who want to contribute to our proposed session in Ann Arbor.

The workshop schedule has been changed owing to changes in the environment. It will be held for three days, Tuesday October 13 through Thursday October 15, in Ann Arbor. There is no charge for the workshop, and you’re on your own for travel and housing.

As this will be a workshop, it isn’t possible to predict exactly what will happen. Our purposes include, but are not limited to:

• Gain a deeper understanding of the dimensions of skill required of team members on Agile projects;
• Elaborate and/or modify the “Seven Pillars” idea to define a framework for team member education for Agile projects.
• Discuss and consider recommendations to Scrum Alliance, Agile Alliance, and the universe at large regarding team member education for Agile projects.
• Discuss and consider group and individual actions regarding the scrum.org and related developments. Decide how we should speak to this issue, and where, so as to guide the community in the best possible direction.
• Discuss and/or demonstrate specific training examples or course materials.

If you would like to attend, and can make a firm commitment, please write an email to Chet’s training address, training@hendricksonXP.com.  We’ll have light continental breakfast and snacks, we’ll be on our own for lunch, and travel and accommodations are up to you. We have arranged for discounted rooms: we’ll let you know when you sign up, and here are the links. (Please don’t sign up for a room until you know whether we are able to accomodate you in the sessions. King Room.  Double Room.)

Scrum luminaries freely grant the necessity for good developer practices, and the Scrum Alliance is thinking about developer certification. Some important people in the community are involved, and so am I. Read on …

Schedule changed, see new post.

Ken Schwaber, co-creator of Scrum, says publicly that perhaps only 25% of Scrum teams get the full benefit of Scrum. Jeff Sutherland, the other co-creator, says publicly that all the high-performance Scrum teams he has seen used XP-style practices.

In those two sentences, we see a problem, and part of a solution. Ken Schwaber has the Scrum Alliance working on a possible “Certified Scrum Developer” program. One thread of work on that involves Chet Hendrickson, Brian Marick, Bob Martin, and Jim Shore. I’m in there as well. Recently Elisabeth Hendrickson has been helping also.

You might be thinking that certification is evil and/or stupid, and therefore why are these people involved in such an evil and stupid thing. For me, my thought is that if certification is to happen, I’d like to try to guide it to be as good and as smart as possible.

The people listed above have corresponded and there was a meeting in Chicago, where we listed seven areas where a development team member needs high skills in order for a team to really rock. We put all that information on a Google group, Agile Developer Skills.

We’re inviting you to join that group. New members will be able to read and post to the general list, and if you want to create and edit documents you’ll need to be approved for that. If you want to contribute–not quite the same as rant–please sign up and help us.

In addition, Chet and I are planning a small no-cost workshop in Ann Arbor, October 12-15, at the Ann Arbor Courtyard by Marriott at 3205 Boardwalk. We’ll be test-flying our presentation and material on the subject, and we expect lots of discussion with attendees on the whole subject of whether and how to certify members of the development team.

We can accommodate around 12 people, so if you would like to attend, and can make a firm commitment, please write an email to Chet’s training address, training@hendricksonXP.com.  We’ll have light continental breakfast and snacks, we’ll be on our own for lunch, and travel and accommodations are up to you. We have arranged for discounted rooms: we’ll let you know when you sign up, and here are the links. (Please don’t sign up for a room until you know whether we are able to accomodate you in the sessions. King Room.  Double Room.)

We’d like to get people who are passionate about excellence, and interested in what, if anything, should be done about certification.

Comments welcome.

TDD, Test-Driven Development, has started out with a very specific meaning, concerning a programmer or pair writing a single test at a time, and making it run, on a very short cycle, as short as ten minutes or less.

Part of the value of TDD is that it makes the programmer’s intentions clear to her–and to her colleagues who may read the tests and code later. Clear intentions are great, and there are other places where teams may really need them. One of these is in the relationship between Customer (Product Owner) and developers.

On struggling or learning teams, we often see the Customer come in with a vague story, talk about it for a while and set the developers to doing it. When they come back, the Customer says “That’s not what I said,” and the developers say “It bloody well is what you said,” and trouble ensues. It really doesn’t matter whether the Customer said it right  and the developers got it wrong, or whether the Customer said it wrong, or whether the Customer has changed his mind. It’s irritating and wasteful in any case.

The standard corrective action for this situation is to express requirements in part with examples. See, for example, the Card, Conversation, Confirmation article from ever so long ago. The Confirmation part is about examples showing how the system should work. It works best, by far, if these examples are executable.

This is clearly the same basic idea as TDD, only written larger. It’s a good thing to apply this kind of thinking at all levels. I’m all for it.

However, let’s not call every ****ing occurance of calling our shot and then executing it TDD.

We did that with Agile. The term “Agile” was vague at the beginning, as an umbrella term covering many methods. It is now watered down to the point where to people who care, a project calling itself “Agile” is assumed to be messed up, and it usually is.

Let’s not water down yet another term. It’s not good for us.

For the past few years, I’ve been doing a little Agile coaching at the Raikes School of Computer Science and Management, at the University of Nebraska in Lincoln. Before Spring Break, Chet and I visited and helped them do a retrospective on last year’s results. In a word: excellent.

This year, we offered to teach a pro-bono Certified ScrumMaster course for the returning leads, to help tune them up for the coming year. The course will be August 17-19, in the lovely Kauffman center on the UNL campus. This will be our challenging three-day CSM Plus course, where you learn Scrum through doing it, with many exercises and very little lecture at all.

We’re opening the course to a handful of paid outsiders. If you’re conveniently located to Lincoln and would like a real Agile workout with a CSM as a side benefit, please consider signing up.