Agile Otter Blog

My friend and colleague Curtis Cooley recently blogged " You Might Have Too Many Developers ." Overall, I agree that smaller teams move more quickly and swarm more effectively on task than large ones seem to, and that there is definite overhead with large groups. You already know some developers are more effective than others.   What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000? Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers. The argument continues describing how many developers are much better than others, and are better in a smaller group than they can be when they are encumbered by less competent programmers. I also agree that smaller teams of more expert programmers make sense on many levels and represent a savings in frustration, cost, and time.   As Red Adair would say : "If you think it's expensive to hire a professional ...

For all the 'take back agile" and "agile smagile" and "apologizing for agile" and all the other post-agilists and so-called post-agilists in the world, I give you Otter's law: Any methodology followed via obligation and knowledge-avoidance cannot produce positive change.  I've ranted about change gone wrong and methodologies followed badly and horrible oversales and undersales and all, but it comes down to otter's law ultimately. Too many companies have huge gains from using XP and Scrum and what-have-you. Too many others tried "the same thing" with entirely different results. Some teams are whole-heartedly into the whole agile thing, and they seem to have pretty good. Others don't seem very excited and don't get much out of it. Is it excitement that they need? I don't think so. I think that the lack of excitement and the lack of progress have the same root. I think it's a lack of profluence in agile-a...

Understand your office situation better w/RSA Animate & David Coplin Raised many interesting points. I still see value in being able to pair and mob, and would like to have heard more talk about that, but I think his idea about being in control of how you work is important. Enjoy.

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

I've had a side-project that started because I've been working with dual-role (and one triple-role) Scrum Masters lately. I appreciate how hard it is for them to be good at several things simultaneously. Once I started collecting techniques for them, I figured I should publish it somehow. I was thinking of a blog, but Joshua Kerievsky (our leader at IndustrialLogic ) had mentioned possibly using something like LeanPub. I really need to learn to release a product early and use feedback to guide it to be something that really addresses a market need. I've invested some odd hours here and there on this, and have gotten some friends to look it over. Sadly, most of them who are dual-role SMs haven't had time. Still, here is a chance for me to learn in a lean startup kind of way, releasing early and often, and let the market help me develop the product further. I'm interested in hearing what you think of the cover, and the idea in general. I've not...

TDD is a pretty simple system, as popularly described.  For an individual doing a kata or playing with some example code it is really just three steps. On card #44 of AgileInAFlash it looks like this: It's the right way to think about TDD, and the right way to get started. When you get to a real project in a team environment you have many other issues to consider.  In a modern team environment, with a DVCS, it looks more like this: Get the current code ( git pull , get clone , hg pull -u , whatever) Run all the tests and be sure they're all really green, to avoid blaming yourself for unrelated breakages. If there are no tests, write a trivial failing test (" assertTrue(false) ") to prove your testing setup (ide, scripts, makefiles) really work. Then delete the trivial test. Write one "real" red test. INSIST ON RED. Write code to turn it green. Local commit "save your game" Refactor (or intentionally choose not to). Check to...

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

The term velocity is very well-chosen. It means speed in a certain direction, with the intention that it refers to the teams rate of travel toward a product release.  I have suggested that velocity is just capacity and my intention was good and maybe even right in many ways. Velocity is the practical measure of our capacity being applied toward the completion of a release. The term still stands superior to my older suggestion. Lets start with the definition that velocity is the speed of progress in a given direction. The direction part gets missed. People (including my slightly younger self) want to do things like track bugs (" failure demand ") as velocity. It might be good to see how much capacity is being lost to failure demand, but it is not velocity toward the same goal, not really.  We don't want to know that the team is busy, we want to see when the project will be done. So we do not count bugs toward velocity. We want to see quality problems drive velocity...

I'm becoming an Esther Derby fan, partly because of her statements about employee motivation and demotivators. . I became acquainted with her work through an agile toolkit podcast in which she was originally invited to discuss retrospectives and making them stick. The conversation turned toward motivation and demotivators, and now I have to go buy some books. Better yet, I need to make some changes.