Agile Otter Blog

Men more brilliant than ourselves have tried for decades to get the idea of quality across to businesspeople and tradespeople (including software craftsmen) and have had only very limited success. TDD is just another grandchild of Quality. http://en.wikipedia.org/wiki/W._Edwards_Deming#Deming.27s_14_points Deming's points didn't stop applying just because we're in software. The excuse,"Our problems are different" was specifically listed as an obstacle to real improvement. But still we feel have to justify the desire to increase quality of our products. Does this seem silly? I spend far too much time trying to get people to build quality in via TDD and JIT inspection (AKA pairing) and collaboration, but still they feel that this is slowing them down. "We all *know* the sun circles the earth, because it rises in the east and sets in the west. Stupid heliocentric theory is a fun pastime for intellectuals, but doesn't work in the real world." My vent ...

What I believe about software development in simple terms: If your team will not pair AND test, if your Customer will not prioritize, if your customer and developers will not collaborate, then nothing you are doing process-wise matters even a little bit. If you have these problems, you might want to forget your standups and scrum-of-scrums, scratch your code reviews, disband the QA team, ignore any promises about delivery. Better to spend your time collecting resume fodder. If these are your problems then change your company, or change your company.

If you have a fixed number of resources, then the only way the team can take on a large new story is by not doing an equivalent amount of previously-assigned work. If the team is honestly working as well as they can, then even small tasks cannot be taken on without other tasks slipping. If they are lazy so-an-sos, or have been withholding effort from you then they can absorb more work. So why is is that when a team can absorb more work without letting anything slip they get rewarded, and when they cannot they are criticized? Doesn't it seem like they should be given credit for really working at capacity all the time? Or maybe it's a wise leader who quietly keeps a small reserve so that he can respond quickly to new requests. Should I, as a manager, keep one or two people working on easily-interruptable, low-value activities so that I can respond when the emergency of the day comes along? There are clearly advantages to both. I've been running fully-committed for a whi...

Today I was in a meeting that made me smile. When I came to this team four months ago (Aug 4th) and took up the agile coach role, I talked about changing how they did ATs. In line with conventional Agile thinking, I told them that the Customer should write them with the aid of QA as subject matter experts. Customer should own the AT, but the QA group could help them flesh out the tests so that they serve the team as requirements and regression protection. At the time, it simply didn't happen. The QA group were writing the ATs on their own back then. This was strange, because they didn't run the ATs and certainly didn't trust the ATs, but they were writing them nonetheless. And they were disliking it. Sometimes the developers wrote the tests for QA, or in pathological cases rewrote them quietly. I am experienced enough to give a consultant's "okay" (meaning "if you insist") and move on to other practices. We finally moved AT responsibility t...

The law of Raspberry Jam is "the more you spread it around, the thinner it gets." A useful principle when dealing with work-in-progress, attention span, goal-setting, etc. I found this gem recited in an email a while back and saved it, without really remembering who wrote it. If you know, please feel free to help attribute it. It quotes Goldratt's /Critical Chain/: There’s a lovely example of the evils of multitasking in Goldratt’s Critical Chain. Suppose you have three things to deliver: A, B and C. Suppose they all take, I don’t know, 2 days each to complete. If you did them one after the other, A will be finished by day 3, B by day 5, and C by day 7. AABBCC. Now suppose you want to satisfy the people who commissioned B and C that you’re paying attention to them, and you decide to multitask. So you decide to split things up, and work on them in one day blocks, ABCABC. The result is that now A is delivered on day 5, two days later than before, and B is delivered on d...

Good advice on how to keep your project from circling the drain. Items #7 through #11 simply do not get enough play. They are: Prioritize Make features, not inventory Leave the team alone. Streamline decisions. Build quality in. When I see teams in trouble, the hardest things to teach are these. Prioritizing means that you have to declare something more important (or at least more urgent) than another. People simply don't like to do that. Making features (not inventory) means that we need to "see the whole" and measure our time from specification to *delivery* not just coding time. We can easily optimize the wrong things and create nothing but trouble, heartache, and last-minute drama. The answer to getting things done is not to have more things in progress. Start rate has to match up with completion rate. If you start too few things, developers are idle and money is wasted. If you start too many things, then it is harder to get any one thing done. You end up wi...

I have to be a little worried about the trickle effect, as it was described to me by my Andrew Cohen (boss and mentor) today. Since moving to Agile, the group produces small increments of functionality every single week. The Customer has more opportunities to decide that a feature is "good enough for now" and move on to more urgent work. That sounds like a good situation. Sure the team is as responsive as it can be to market needs, and sure the most important work is what gets done, and sure it's in measured weekly bits. But this isn't what people come to expect from a software team. Since there are no large quarterly or monthly releases, it seems like nothing big ever gets done. If we release every month instead of every quarter, we get 1/3 sized releases. If we release every 2 weeks instead of every 6 months, we get 1/13th sized releases. They're "less" though "more often." Where is the PR event, the release party? Is last week the poi...