- Agile Leadership Development
- Product Owner
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.
How did we arrive at this place where so many people believe that self-organizing teams do not need help? The fact is, self-organizing teams DO need help.
What teams can experience: Teams might not know exactly what kind of help they need or even how to describe it. This can be especially true if they had a manager-led team and were told what to do and when to do it. I hear teams say, “we don’t need managers”, but they often mean that they don’t need managers telling them what to do.
What managers can experience: Managers are often put in a position of shifting from being an expert and telling teams what to do to some new approach that is not clear to them. They may not know exactly how to help a self-organizing team. I call this clumsy management. It is not that they are doing it on purpose, they just happen to be bumping into things when trying to help. Managers are sometimes told to “stay out of the team’s way”, so they end up disengaged and not sure how to reengage. The fact that a manager may not be sure how to help a self-organizing team does not mean that help is not needed. Read More
Scrum changes the way everyone in your company interacts and will likely influence your organizational structure.
When an organization considers “moving to” Scrum, it’s easy to think that Scrum is a new process that just needs to be learned and implemented.
“This year,” says your friend (who’s never run a 5K), “I’m going to do a marathon.”
“Yeah? How are you going to do that?” you inquire, trying to sound polite and curious rather than incredulous.
“Well, I haven’t figured that out yet…but I’m looking at maybe Chicago or Boston…”
Last month we talked about good software design and introduced the notion of code smells. Code smells are names given to those instinctual thoughts you have whenever you look at a chunk of less-than-elegant code. Some are subtle, and some really stink.
I’ve learned not to assume a team has experienced a variety of software design skills. Some are writing elegant functional-paradigm code in archaic, challenging languages. Others are writing strongly-coupled, heavily-commented, and procedural static methods in Java or C#.