Agile Otter Blog

The team I have been working with has been reporting a surprising amount of time on merging forward branches, merging them to a RC, and dealing with merges that were not done correctly. This just supports my thesis that branching is a wasteful practices. What I think makes sense is that a team (whole team) is given sufficiently small jobs that any one of them can be completed within an iteration. Anything the team starts it also finishes. The team also commits to the creation and use of unit tests (preferably via TDD) so that the tests they have written give them confidence that they've broken nothing with their most recent changes. I see the team working in a common code line for all new work. This can be trunk, or a common branch. As work completes, the CI server runs all the tests (UT and AT and anything else they can automate). If all the tests run, the branch is tagged as a release candidate. When it is time to release, an existing release candidate is chosen as the next ...

RandsInRepose writes the best article I've seen in a long time. I am also daunted by large tasks, and especially large learning tasks. Even large drudgery tasks can give me pause from time to time. His answer is so simple, and so reasonable. Start. Iterate. Mix it up. I noticed in the tree story that he had one more bit of advice -- get some help. Nice points to ponder.

Branching is a coping mechanism. There is a lot of branching and release-time cherry-picking of features in the commercial software world. It seems to alleviate some pain and make the process more manageable, but I fear this is at too great a cost. Many development groups branch due to dysfunction. Note that I am not talking about open source projects. I'm specifically speaking about commercial projects where programming talent is not free. I'm also not talking down distributed version control, where every checkout is really a separate branch. I am concerned more about use of branches for the wrong reasons and at a high cost. Often branching is used to put off integration. This is a losing game. After so many changes to the trunk a branch will no longer slide seamlessly into the release stream. We can work around that problem (itself a work-around) if we merge forward all branches periodically so that they track the trunk more closely. This activity is time spent on featu...

When faced with ugly code I learned a simple pattern. First I would break the code into paragraphs and comment it liberally. Since I hate code that requires comments, my next step is to take one comment at a time and change the code to make the comment unnecessary. Often that is the matter of changing a variable name or function name. Sometime it takes extracting a function or method. Sometimes it means introducing explanatory variables. Eventually the code doesn't need any of the comments anymore. It is smaller and cleaner and usually faster as well. Then I started working with teams. I found that teams accrue process and practices the way that code acquires comments. They are in a difficult situation, and so they add more steps, more process, more tools, more tricks. Ultimately ripping away the existing process will leave the team with the original problems and no coping mechanisms, just as deleting comments would have left the code just as crufty and perhaps more unread...

On Aug 4, 2008 I moved from Object Mentor where I was an Agile coach and mentor to various companies to Textura where I have been an internal coach and now am managing a team of developers. I realized that I need a new professional outlet now since I won't be filling up the pages of the Object Mentor blog. My friends recommended that I start working on personal branding by starting up an individual pro blog outside of my work environment. I will be writing from myself, and not from the point of view of any employer. Welcome to the result of that. Now I am working the agile transition from a whole different angle. Hopefully, this will be a great time of growth for me as well and I intend to blog my observations about agile practice as usual. I hope it will be a place where people can participate by giving me new observations, advice, and even possibly an occasional boot to the head. Enjoy. We will cover many miles together.