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

This is a mostly-verbatim post from a LinkedIn forum.  I thought it was worth sharing with the audience here, so you can help me refine my thinking. In the forum, another member suggested that agile and waterfall are opposite ends of a spectrum. He further suggested that a team can choose its own position along the "sliding scale" between the two extremes.  This is when it dawned on me that maybe I understand why this is not true.  Please pipe in with your insights, extensions, or corrections. It is possible that agile and waterfall are not two approaches to the same thing. If they were two approaches to the same thing, I think mixing them would make sense and the sliding scale makes sense. If, however, they are two different systems with different axiomatic bases, then the reasoning that is productive in the one will be surprisingly counter-productive in puzzling ways in the other. I suggest that the systems are axiomatically different. Agile values c...

How it Happens You realize that you're not getting as much done as you expected to get done. It's troublesome because you have plans and promises and releases to deal with. You're likely to end up the scapegoat when your behind-ness snowballs into a large organization-wide issue. You also have quality problems. Your team leads estimate that the teams are spending 70% of their effort on defect-fixing activities.  It dawns on you that you can get back 70% of the productivity of your team if you can spin up a separate team to handle bugs! Now one team can be 100% dedicated to adding new functionality without being encumbered by bug-fixing work.  After months, you find that the defect density has not improved from your effort. You see a ramp-up in the number of defects fixed per month as the bug team's diagnostic and corrective skills improve, but they are still lucky to hold even against the tide of defect injection. Why doesn't this work? What has g...

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

State of Practice: Scrum I participate in a number of forums where I am happy to help people understand agile methods and practices. I see dozens of question s every week asked (and often answered!) by people who are operating in a system they simply don't understand. For instance, one very well-intended manager called a meeting with HR and consultants and leaders of teams to decide what a scrum master's duties are, and what a PO's duties are. Only the consultant had ever read t he scrum guide ; the rest were going to invent roles to match their current job titles. Not understanding that people can rotate roles (and roles can even evaporate), the HR wanted to make the roles have specific meaning benefit-wise and hire specifically for some of those roles. In an online forum, a manager asked "since release schedules are fixed, how do you make up for slippages in sprints." This belies that the project plan was a big-project plan (BDUF-style) divided into sprint...

Eric Ries has suggestions on why/how to move your engineering practice forward and gain speed and reliability while you're at it: So how can I help the engineering manager in pain? Here's my diagnosis of his problem: He has some automated tests, but his team doesn't have a continuous integration server or practice TDD. Hence, the tests tend to go stale, or are themselves intermittent. No amount of fixing is making any difference, because the fixes aren't pinned in place by tests, so they get dwarfed by the new defects being introduced with new features. It's a treadmill situation - they have to run faster and faster just to stay at the level of quality/features they're at today. The team can't get permission from the business leaders to get "extra time" for fixing. This is because the are constantly telling them that features are done as soon as they can see them in the product. Because there are no tests for new features (or operational...

Wherever I go, I find people who want to "implement agile" but they want to start with processes and tools. They could develop techniques first, but they want to begin with working at a very large scale and comparing capabilities across teams and maintaining individual accountability and individual review. They want a big program they can plug into their existing system. A lot of organizations want to "go agile" starting with long-range planning, so that they can control the direction and results of the agile teams and track their progress toward n-year goals. They want an agile way to drive their teams in a straight line. Some corporations have layers of hierarchy devoted to contacting customers, usually in the interest of controlling perceptions and getting marketing intelligence. They wouldn't let developers within a mile of anyone who actually uses the software, for fear that they would let the internal culture and personality of the company leak out. O...

(note: I added a 15th, but was worried that changing the title would invalidate links, so you get a bonus observation at no extra cost) I frequently have to address questions about velocity, so in the interest of time I present all the answers here in a short post: Velocity is a gauge, not a control knob. You can't just turn up the velocity -- you can only break the gauge by trying. Velocity is (frustratingly) a lagging indicator. It primarily tells you about the fundamental process and technical work you did weeks, months, or years ago. You seldom get an immediate, true improvement. Though velocity is a gauge, it is subject to  Goodhart's Law . It is rather dodgy when used as a basis for governance. Velocity value is highly derivative of many factors, chief among them being the work structure of the organization. The more governance and procedure (permission steps, queuing and wait states, official limitations,  risk of personal blame, reporting and rec...

I know it's going to sound like I'm trying to talk my boss and yours out of giving us both raises, and of course I'm not, but I keep hearing people tell me they're worried that they can't work in teams because their system pits them against one another. Usually it's an excuse or reason for not pairing. "If I improve my colleague, he will beat me to the incentives" or "if we do his work first, then there's a chance I'll fall behind."  I'm not a fan of individual work assignments , and I'm not a fan of competitive incentives . Rather than rant about it, I'd like to point you to some other authors and how they feel about the topic: Daniel Pink suggests killing your performance ratings . InfoQ balanced comments pro and con individual rewards. Peter Scholtes says reviews are  ineffective, even harmful  and performance appraisal are incompatible . Esther Derby suggests ways to support team-based work  and  performance ...

Famously, scrum has used an old joke to explain two kinds of participants in development work. Pigs and chickens is a reference to having bacon and eggs for breakfast; the chicken is involved (donates an egg), but the pig is committed (gives his all).  In scrum, this translates to stakeholders (chickens) and material participants (pigs). It always seemed funny that people who are on the hook to pay for the work are chickens and those who are paid whether or not the product succeeds are pigs. Still, I appreciate calling out the idea of advisors and stakeholders v. material participants. I wonder sometimes about those roles for people who are not primary stakeholders, yet are somewhat involved in the development, but primarily act to give permission or to grant or withhold resources. Are those chickens with a pig complex? Pigs with chicken complex? Porklucken? Non-coding architects who must approve designs Sysadmin/IT who controls the team's computing resources Externa...

See the recent article on management lessons from Linus Torvalds.  Some important call-outs: On external quality: Torvalds concludes, “Way too many projects seem to think that the code is more important than the user, and they break things left and right, and they don't apologize for it, because they feel that they are ‘fixing’ the code and doing the right thing.” On tooling: “I don't think tools are all that fundamentally  important.” “Now, what is important is that there's  a good workflow for the project , and tools can certainly help with that,” said Torvalds. “But most projects don't necessarily really need tools. There's a lot of projects that simply don't have enough changes to really require any tools at all for their work flow; [...]"

A common question on the TDD and XP mailing lists is how to get managers to approve refactoring and testing. The standard response is to ask in return why programmers need permission to write code that doesn't suck. The problem is that it is hard to know how to manage software development in a condition of rising Technical Debt . I was a programmer a long time before doing any management. I had to learn to manage my unit of work, to do things people wanted to have done, etc. There is a certain amount of professional discipline necessary to be a good employee-programmer. I had a tendency to do X (which was required) and throw in some Y and Z. Where Y and Z were simplifications along the path to doing X, it's all good. This shouldn't need permission (one would hope) but what about when they were solving miscellaneous potential problems on the side? What if they scratched an itch? Under the reign of SAS70 interpretations and ISO 900x dreams and basic risk management, I...