Agile Otter Blog

We recently started talking about Taking Agile Back . I was surprised to hear how much response came from this. Now we have a community on google and presence on linked in and yahoo groups and twitter . People are coming from the woodwork to say that they're also sad about the state of agile practice and they either yearn to return to agile values, or they lament that they never were able to enjoy really practicing those values. But what do we do? I think that there are at least three immediate steps we can take. Remove barnacles Reinstate values Move forward Remove Barnacles The first is a tad negative. We should call out the things that have grown on the skin of agile (shallow, peripheral issues) and have obscured the heart of the principles.  I've already addressed some of the noise that has grown up around velocity and estimation . I've been suppressing a number of opinions on metrics and disengagement.  You can love or hate Linked-In, but ...

Within my company, we're talking about agreements and expectations a lot. Safety in decision-making and action-taking is all caught up in expectations and working agreements, and many of ours have been unspoken, unwritten, and un-negotiated. As a result, it is easy to drop things, expecting others to pick them up when they don't know to do it. It's also to do things that seem to step on your colleague's toes or which work at cross-purposes.  I was doing some work for a very dear client of ours, and I needed to revisit the Debian New Package Maintainer's guide . What appears on page one? A set of working agreements. We all are volunteers. You cannot impose on others what to do. You should be motivated to do things by yourself. Friendly cooperation is the driving force. Your contribution should not overstrain others. Your contribution is valuable only when others appreciate it. Debian is not your school where you get automatic attention of...

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. -- "The Retrospective Prime Directive" by Norm Kerth Software, as Dr. Ralph Johnson informed us, is distilled experience. Writing software, Ray Scheufler reminds us, is a process of making decisions. To make decisions, we have to understand the system we're working in, and the consequences of our decisions. That means that most of the work of a programmer is learning, and very little of it actually involves typing. Understanding any existing body of software is involves understanding the domain,  the user being served,  the specific problem being solved,  the solution chosen,  the techniques of safe software development,  the organization producing the project, and  the technology (language, operating system, network...