Agile Otter Blog

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

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

Today we held the first ever Puzzle Challenge at my client's site. The goal of the challenge was for each team to pick a work style that aided them in getting the greatest number of puzzles completed in a very short time (10 minutes per sprint). The set of puzzles to solved was a mix of crosswords, mazes, word-search, sudoku, word jumbles, and number blocks. The teams were told that there was no partial credit at the end of the ten minute sprint. The teams were given a menu of practices to choose from: Team members could one mode of adaptation, leadership, teamwork, noise level, and task switching. A style of 11111 would mean a 1 in each of these categories, a style strongly resembling an "ideal" organization in the buttoned-down 80s. A style of 33333 is basically a productive chaos, which might have been more widely recommended in the free-spirited 60s. Teams made an initial selection, then were allowed some adaptation. In initial selection of work s...

Your team is hard at work, testing and coding and planning, and suddenly the build breaks. Now what can you do? The broken build might not be your fault at all, and besides you have work of your own to do. You could go ahead and practice business-as-usual, but this is probably a bad idea. Here's what I say: Never pull from a broken build . Assume that version control is poison. If you are not the one fixing the build (and shouldn't you be?) then you should leave it be. The last thing you want to do is import brokenness into your local build environment. Import from a "green" build, and you will know that any brokenness is your problem. Test locally before considering pushing code to the CI build, even though it takes a bit more time. There is really no good time to NOT know that you've broken something. A little "due diligence" goes a long way. Never push to the CI server if your local build is broken . If your build is broken, it inconveniences...

Just for the record: it is flat out impossible to "do the tdd" after the code is finished. This is just a matter of definition. You can write tests after the code is finished, but that has no relationship to TDD whatsoever. None. Nada. Zip. In TDD you write a new, failing test. Next you write enough code to pass the test. Then you refactor. This repeats until the code is done, writing and running tests continually. It shapes the way the code is written. It is a technique for making sure you write the right code, and that you do so in an incremental and iterative way. In ATDD, you have a failing acceptance tests. You take the first failing tests (or the easiest) and use TDD to build the code so that that part of the AT passes. You run the AT after each major step that you've built using TDD. When the AT is all green, you have completed the feature. This helps avoid early stop and also helps avoid gold-plating. If tests were product, then it would make no difference...

Overall, pair programming isn't as controversial as you've heard. It depends on your styles of pairing. Some styles of pairing are very common, even among non-agile teams. They tend to be episodic, and last just long enough to get or give some aid. The good news is that they work. If a team views pairing with trepidation, these are common, non-threatening forms to start with: Rescue Pairing Training Pairing Brainstorming Experimenter/Researcher Others are such bad ideas that they are rightfully avoided by all sane teams I've seen so far.  If you are considering pairing, and a team member balks, you should see if their mental model of pairing matches one of these styles. I suspect a team should decide that these styles will never be practiced personally, or tolerated within the team's pod.  You have my blessings to object to pairing if "pairing" means: Worker/Rester Worker/Watcher Master/Slave Bully/Victim Writer/Critic Ball-and-chain pair marriag...

It's a common thread in agile transitions that people are not sure what pairing, teamwork, and self-organization will do to their status on the team. Will the team be so leveled that nobody will stand out? Will the weak be exposed and humiliated? I am going to write this as if there were two states, strong and weak. Before reading anything that follows, remember that everyone is good in some areas and weaker in others. I have seen javascript gurus who weren't very database-smart, and people who were great with requirements and product knowledge but had no sense of scalability or performance. Any human characteristics are spectra, not point measurements. With that in always in mind, read on: There is good news, more good news, and some hard and potentially sad news in all of this. The first bit of good news is that nobody who works in an agile team ever asks these questions. In reality, it's not a problem. Let's get down to cases. Rockstars If you are the rock s...

It is a tempest in a teakettle, to be sure, but among the points of friction and discovery today was one about the use of the letter 'u' as a variable name. The case in point was a nice, small function, not much larger or more complex than this stupid example: public void Whatever() { User u = new User(); if (u.hasSomeAttribute()) { u.setSomeValue(); } } The focal point is the letter U as a variable name. Because of my involvement in a particular book project, I was summoned into the conversation and carried half of it for some time. I would rather see "user" than "u" because of my rules about pronounceable, grep-able names that don't require any mental mapping. That is my preference. Therefore, I can clearly NOT choose the variable name "u." I also have publicly stood by James Grenning's assertion that the length of a name should have some correlation with its scope...