- Agile Leadership Development
- Product Owner
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#.
“We need you to help this team. They are struggling to deliver. But don’t worry; you’ll love this team. There is no conflict and they are willing to help each other.”
I was assigned as the ScrumMaster for this team many years ago, and this is how my boss described the team I’d be a part of. Every part of his statement was true because this team had settled. They settled for cooperation instead of working toward collaboration.
As an Agile trainer and coach, I have worked with hundreds of companies over the past 10 years. After reflecting back on my interactions with all these companies, I have found there is a strong correlation between a single decision companies make and how much dysfunction there is in the company.
I was recently asked about the difference between unit-testing and Test-Driven Development (TDD). Specifically, why—if the end results are the same—would I recommend TDD over writing unit tests after coding?
“Engagement doesn’t really matter in the workforce today”
That’s not a real quote. I’ve never heard a leader say that. But something doesn’t add up.
What are the Agile Engineering Skills, Scrum Developer Practices, or Software Craftsmanship practices?
These are three (of many) common names for a set of practices assembled in the mid-1990s to support and improve Agile software development efforts. They are a collection of practices that help teams work in an incremental, iterative, and simultaneous way (i.e., all functional departments working towards a clear goal on a continuous basis, and not waiting on each other at explicit or implicit process gates).
They were first combined as a complete collection of practices within Extreme Programming, another popular Agile method, around 1996.
It’s a classic facilitation blunder: You start giving instructions for an activity, and as you’re talking, people begin the activity. You try to reel in those eager participants so you can get the rest of your instructions out. Then, as everyone starts, you realize you forgot something important and need to get the group back together for more instructions.
The best facilitators are extremely deliberate about how they give instructions. Read More