- Agile Leadership Development
- Product Owner
“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
A major challenge we run into when helping organizations shift or improve is leadership misconceptions. Agile leadership myths cause a lot of these misconceptions. We need to help avoid falling into the trap of these common myths because they limit our success. A root cause of many of the myths is that people simply don’t know what else to do. For example, Myth #1: ‘telling people “you are empowered” actually works.’ Leaders often don’t know what else to do, other than tell teams they are empowered. We see this with Development Teams, Scrum Teams, Delivery Teams, AND Leadership Teams.
A bit of background — there are many agile leadership myths out there. These myths (or assumptions) limit leaders ability to improve, help others, and succeed. Many myths seem to occur at a nonconscious level, meaning they function like many biases. People are not even aware, consciously, that they are happening. Read More