- Agile Leadership Development
- Product Owner
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
I was co-training an Agile for Teams workshop with Rob Myers last week. This group had been trying to do Scrum, with some success. Our job was to help them solidify their Scrum practice. I love workshops like these. There’s enough knowledge and experience in the room that if willing to learn, can create a huge uptick in satisfaction and performance. Fertile ground for the ‘aha’ moments!
At one point the managers left the room so that the teams could, without fear, talk about what they were going to do differently going forward. The managers suggested they leave. A nice move on their part, and one btw I hope in the future they don’t have to repeat as the organization embraces the Scrum Values. But given where they were in the journey, it was a great offer.
When the teams had talked about what they had learned and what they thought they might do differently, we debriefed a bit. It was a great conversation, with a lot of the ‘aha’ learnings. However, for me there was a lack of clear action as an outcome of the debrief. I asked, “When the managers return, what do you want to tell them?”
We require environments where people can provide input and ideas. If we limit engagement, we limit success. We still have organizations who either believe or act like they believe some types of workers are “stupid.” This idea dates back to the ideas surrounding Scientific Management, Fredrick Taylor, and Henry Ford. The concept of the stupid or unskilled worker that I mentioned was common in the early 20th century. In various writings about agile and agile ideas, we often refer to or see references to avoiding Scientific Management, Classic Scientific Management, or Taylorism. These management ideas limit engagement from people, which is going to limit success.
Understanding the past can be quite helpful to see where you might be able to improve today. Read More
Let’s cut to the chase: No one likes meetings. A status meeting every day is enough to drive you crazy.
As I train and coach Scrum across the country, I’m often struck with the power how certain words can create a sense of fear in people. In my experience, no word creates as much fear as ‘commitment’. Yet commitment is one of the five Scrum Values per the Scrum Guide! IMHO, that’s a problem.
I too was once afraid of the word ‘commitment’; although, I’m going to claim with good reason. Back in my enterprise days, (I worked in large corporations for the first 30 years of my working life) we once engaged the services of a consultant who said that people should make very clear commitments. So far so good. Read More
Welcome to my new blog on the Agile for All site! Along with new posts, I’ll be interleaving updated, edited, and timely posts from my earlier independent blog. My posts will lean towards technical practices and skills, but always with an eye towards the business value and the humanistic dimensions of those technical topics. Here’s an example…
Many years ago, Ward Cunningham posted an excellent video on YouTube regarding refactoring and “debt”. If you haven’t seen it, I have it for you, below. But is “Technical Debt” simply a metaphor, or is he describing a real fiscal debt associated with software development activities? Read More
I’m a pragmatist. I need things to make sense. So, when something like principles are introduced to me, I start to ponder questions like… What is a principle? Where did these principles come from? Are all these really principles? How do these principles relate to each other? Why should I care? Etc. Yep, I can get myself tied up into a knot thinking about all that. However, in that thinking I can find a nugget of learning. (While other times, I capitulate and get a beer.)
I’ve done a huge amount of thinking about principles. Relative to many of the questions above, I’m still
drinking…thinking. However, I have thought AND experienced a lot about applying principles and values in my Agile coaching and training.
The word principle comes from the Latin for ‘source’ and ‘foundation’. The definition of principle is “a fundamental truth or proposition that serves as the foundation for a system of belief or behavior or for a chain of reasoning…a fundamental source of basis of something”.
Principles are discovered. They are the underlying understanding of why things happen; how things work.
Does this sound familiar?
I was a Program Manager for over a decade, during which time I must have facilitated dozens of “project post-mortems”, a term that always bothered me, since in none of those projects had anyone died. One of the key “Lessons Learned” from nearly every post-mortem I facilitated was some variation on this: “We Should Have Planned Better”.
Of course, we always did the best planning we could, given what we knew at the time. Software development, like many types of work, is inherently unpredictable. We always learned quite a bit more as we went along building things, testing them, and reviewing them with customers and stakeholders. In all of those post-mortems, we learned the wrong lesson. We fell prey to a cognitive bias known as Hindsight Bias.