- Agile Leadership Development
- Product Owner
Next year I’ll likely be teaching Essential Test-Driven Development to a team that includes about 50% COBOL programmers. I told the client I’d look for a good object-oriented (OO) primer for those developers to read in advance. As you can imagine, it’s tough to “unit-test” software that doesn’t have clear “unit” boundaries. COBOL relies on a lot of global state, and this appears to be true for this client.
Occasionally, I’ve been asked to help design team rooms for a client. They may have been planning to hire an ergonomic architect/designer in addition to an Agile Coach. Great, but before they got that far, I had two suggestions for them:
- Involve your existing Agile team members in discussions in order to uncover their needs.
- Involve someone who has actually been on a number of Agile teams in a variety of spaces. Of course, I volunteered me! When I’ve acted as XP coach (mostly 1998-2004), I sat with teams and wrote code.
Earlier this summer, an event that has defied naming was held for the sixth consecutive year. Agile For All’s advanced training event, Humanizing Work, took place in the mountains of Colorado in Beaver Creek, with 99 people in attendance.
You’ve heard the old adage about the lumberjack who—in order to cut a tree in an hour—will take 45 minutes to sharpen the saw? This old analogy really needs updating: Not many of us are all that familiar with the logging industry.
I like to instead use the metaphor of the chef who sharpens her knives before cooking.
In our BDD course, we use a real example of an online library patron portal. Course participants are provided with a number of (often vague) business rules regarding whether or not a book loan can be renewed. Some have to do with the state of the book (e.g., has another patron requested a “hold” on the book?) and others on the loan, itself (e.g., has this patron already renewed twice?).
We have done a huge disservice to leaders and managers, as well as teams. There are plenty of people that will say we don’t need managers and leaders. People can lead themselves. While there is an aspect of this that may be true, there are a lot of steps to get close to that idea.
This article will explore what leaders and managers need to do to succeed as they get started with agile or to help teams move from individuals to a team or even a high-performance team. It builds on Agile Leadership Myth #2: Self-Organizing Teams Don’t Need Any Help. Read More
I often get questions about testing “the user interface” or “the front end.” This comes up in all our technical Agile classes (Behavior Driven Development, Essential Test-Driven Development, Certified Scrum Developer), or most frequently during coaching.
We’ve seen how refactoring becomes the primary design activity on an Agile team. Diligent, confident refactoring is possible to the degree that the code is tested through an automated test suite. If the tests don’t cover a portion of the code, a defect may be introduced when that code is altered. If the tests are slow, they’ll run less frequently, and the time between the introduction of a defect and the detection of that defect is slowed.