Agile Otter Blog

I was chatting with a manager who was once a PO on a team I coached many years ago. This is only my best memory of the conversation (I didn't record it at the time). I may have slightly embellished it with snippets from conversations that followed over the course of days or weeks, but I try to be faithful. One day she took me aside and asked what she should be doing to accelerate the team and get more work pushed through. “Nothing,” I said. “Nothing? But I thought that I’m supposed to be getting maximum work and speeding up the team…?” “Nope. Your job as PO is to maximize the value of the work, not the quantity of the work. Given that they’re doing roughly the same amount of work each week (barring emergencies and vacations), your job is to make sure that what they are working on is the most valuable work that they could do that week - that it is impactful and useful.” The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Te...

Including delivery/deployment in the definition of done I'm told is unfair because teams aren't in control of what gets delivered or when. "Their work might be completed, but be only a fraction of some larger scatter-gathered effort, so it's not their fault." "They may be dependent on work from another group, say FE or BE or database, or something, so it's not their fault the work isn't done." "They may have worked on a dozen things, but only one was delivered. It's unfair that it doesn't represent all of their efforts." "Releases aren't done every sprint/increment/week/whatever, so it will look like uneven velocity if we only count work actually delivered." "They should be able to count the points for everything they worked on, whether it's delivered or not." "A manager may decide not to release their feature and leave it in the branch -- maybe never release it. It's not their fault so...

So a given web application has an architecture that involves a UI and an API and under that some domain objects, data, etc. When a new feature comes up, there is a gherkin test that does NOT go through selenium, but directly to the API. In developing the gherkin test, the team drives out the changes needed by the API and gets it working. The gherkin test is a "story test" and checks to see if the system (behind the UI) works correctly. It does data, persistence, etc in a safe way. But to build the code, you are doing TDD directly on the API and the deeper domain objects. As you do, you are refactoring and committing (of course). The microtests and the gherkin tests together are super-fast, so you run both in the auto tester . The auto tester re-runs the tests any time the code is changed and compile-able. This means the tests are run many sometimes more than once a minute. You're always clear where you stand. But of course, there is a web page to deal with. You create r...

Quite some years ago, Brett Schuchert and I invented the acronym FIRST for micro-tests , though we called them "unit tests" (as was common at the time). This was later included in Agile In A Flash and was also published in a Pragmatic Programmers' article. It’s grown a following and has been widely repeated. At this point, the idea just exists in the aether, and authorship isn’t often considered or cited. I suppose it has become "common knowledge" at least in some circles. It's usually not even given a citation, so I guess it's become a thing in its own right. I’m still proud of Brett’s work and my small contribution to it. I'm glad it has taken on a life of its own, but I'm aware of when it's poorly described or when it's corrupted and am offended when people present it as their own unique work (or take praise for it, knowing that it is not original). I get it, though. I'm sure there are many people whose work I didn't know how ...

 (originally posted in march 2008, republished with edits) I read a mailing list entry in which one fellow (who? I can’t remember!) asked another: “Do you want to get better at what you’re doing, or find a better way to get the results you want?” I’m a sucker for a good one-liner. That one had me thinking, and as I’ve had other conversations about innovation, I keep coming back to that line. In many Agile practices, we work really hard for a week or two, and then hold a retrospective. The purpose of the retrospective is to find  ways to work more effectively for the next two weeks .  As we develop better software, we also evolve a better team. We may use “tricks” such as tracking our velocity and recording blockages on our ‘waste snake’ to provide data for our decisions, and we use gut feel to evaluate those things that feel like collateral effort to us. If the practice works, we will see incremental improvement in the team. We will develop ways of avoiding special variat...

  Originally Posted   on 2/26/2007 One of the more annoying problems in code, confounding readability and maintainability, frustrating test-writing, is that of the multidomain variable. I suppose somebody forgot to clue me in to the Great Variable Shortage that is coming. I have seen people recycling variables to mean different things at different times in the program or different states of the containing object. I’ve witnessed magic negative values in variables that normally would contain a count (sometimes as indicators that there is no count, much as a  NULL /nil/None would). I might be willing to tolerate this in programming languages where a null value is not present. Yet I have seen some code spring from multidomain variables that made the code rather less than obvious. I think that it can be a much worse problem than tuple madness. I have a rule that I stand by in OO and in database design, and that is that a variable should have a single, reasonable domain. It is ...

In light of recent outrages, there are a lot of people posting bloodthirsty things on social media. If you post bloodthirsty things, I want you to know I don't stand with you on that. I may agree with your underlying cause(s) and reason(s). But I don't want people to be killed. I don't want looters to be killed. I don't want protesters to be killed. I don't want suspects to be killed. I don't want curfew-violators to be killed. I don't want civilians to be killed by cops. I don't want cops to be killed by civilians. I don't want politicians killed. I don't want community leaders to be killed. I don't want bystanders to be killed. I'm not claiming that all of these things are equivalent. The only equivalence is that I want all these people to go home at night, and justice to be accomplished without bloodshed. I'm not suggesting outrage is unfounded. I'm not saying nothing should be done. I will suggest that if escalat...