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

The agile value of the day is Discipline, the D word. With it we avoid being overwhelmed, snarled, and demotivated. Without it, nothing goes well. Here are my top 8 items in the "fruit of the agile spirit": Refuse to complicate your system. Don't break ranks Be transparent even in difficulty Work in very small steps Maintain/increase quality Impose simplicity on software. Build a better "next month" Go home before you break something. These very simple things can be very difficult, but they are very important and simple nonetheless. When I find myself going wrong, it is because I've broken from these simple ideas.

The new team is great. We've put some extreme measures in place, but we're getting some focus on getting real completion. To deal with the huge QA backlog, we have devoted 2/3 of our programming staff to dealing with making software releases (dealing with old bugs, bringing code forward from the dark ages to current trunk, etc). We rotate the team roster randomly so nobody is stuck doing the dirty work all of the time. Nobody expects this team structure to last. It has changed how work is done, though. More people know more things about more parts of the code, and work no longer queues for individuals. We make weekly releases. We're not fully agile, but we've been moving the right direction. There isn't full test-driven development and full pairing, so we're slower and less certain than we should be right now. In fact, we're just hitting that hurdle where there are so many non-unit tests that it takes a half-hour to run them all. Clearly we have t...

So you're looking at this pre-existing code. You aren't sure what to do with it, but you need to get some unit tests going. What do you do when you get stuck. Start by testing you can instantiating the class. Test that you can call the function at all. Pick the easiest bit of functionality. Write the name and assertion first. Write the function call as you would like it to appear. Refactor the existing tests. Pick the most interesting bit of functionality. Switch partners. Read the code for obvious flaws. Rerun the AT Again, this is part of the work being done by myself and Jeff Langr .

Mike Pirnat found a snippet of python code. I can only suppose it was written as a joke. Python is such a readable language left in something approaching a "natural" state. This code looks like an entry in the old C obfuscated code contest. It uses a lot of the same tricks they would use back then, though we don't have any way of writing proper macros. It could have gotten much worse if they really wanted to stretch with lambdas, comps, generators, localizing methods, misusing decorators, etc. Personally, I think it's a great example of how important naming and tidiness are. If you can make a great language like python look like a load of manure, then imagine how "clever" programmers can do evil in languages like C++, Java, or even Ruby. Bad code is a matter of intent (or default, in some cases). Good code is intentional. All our code should not be joke code.