Agile Otter Blog

In the last installment , we talked about reasons that velocity goes up without any more accomplishment by the team. This is a disturbing occurrence to many managers who want to use velocity as a measure of productivity, and their insistence on treating low velocity as a productivity measure. We'll pick up the conversation from there. A: I don't  like  the "estimating in larger numbers" explanation. What is an alternative explanation? B: Perhaps they've developed skills, knowledge, and/or techniques that make it easier to get more work done. There are a few ways of measuring efficiency. One of the least useful is output over time. If one team of people produce more in a week than another, isn't the one more efficient? It's not possible to say. They may put out a disproportionate amount of effort in order to get a higher yield. That could be arguably more productive  but it is not more efficient . If it's harder to get more work done, then yo...

Communication is a very human process. A quick model Every being has its own mental model of a domain Connected to it is a hearing/understanding apparatus. When you tell me the sky is beautiful, my mental model suggests it is a nice shade of blue and had some light, interesting clouds. But it could be that we don't share a model, and you meant really intense lightning and fast-moving thunderheads. Provided that there are not too many great disconnects, though, what you tell me may provide information that I can add to my mental model. This is true whether I understand the words I heard in the same way that you meant them or not. Recognize there is a difference between what I hear, and what I understand. It is sometimes said that "memory is the residue of thought" so my memory of our conversation may not be my memory of the sounds and words used, but of my thoughts/interpretation of the sentences as they occurred. I probably remember what I was thinking while you...

Bridging two worlds is not easy. See if you can spot the non-agile assumptions in all of these questions: You find one team is only meeting schedules and pleasing customers because they have been padding schedules and cutting scope. How can you get them to plan and execute more aggressively?  One of your teams is hogging some of the QA resources full-time, and have been since the start of the project. How do you ensure you'll have a full complement of testers for your other team's testing phase?  One of your teams has stopped turning in estimates and long-range plans. They seem to be producing well enough, but how do you reign in their manager without hurting productivity?  Of your two teams, one group works overtime and weekends but the other refuses to stay late even during mid-week days. You have many projects in the pipeline. How do motivate those clock-watchers?  Your team has severe technical problems, but instead of keeping their nose to the grindstone,...

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...